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

Tìm thấy 1221 câu.

Câu 151 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A company runs a suite of web applications in AWS. The application is hosted in an Auto Scaling group of On-Demand Amazon EC2 instances behind an Application Load Balancer that handles traffic from multiple web domains. The solutions architect is responsible for securing the system by allowing multiple domains to serve SSL traffic without the need to re-authenticate and re-provision a new certificate whenever a new domain name is added. This change of architecture from HTTP to HTTPS will help improve the SEO and Google search ranking of the web application.

Which of the following options are valid solutions to meet the above requirements? (Select TWO.)

  1. A

    Create a new CloudFront web distribution and configure it to serve HTTPS requests using dedicated IP addresses in order to associate your alternate domain names with a dedicated IP address in each CloudFront edge location.
  2. B

    Add a Subject Alternative Name (SAN) for each additional domain to your certificate.
  3. C

    Use a wildcard certificate to handle multiple sub-domains and different domains.
  4. D

    Upload all SSL certificates of the domains in the ALB using the console and bind multiple certificates to the same secure listener on your load balancer. ALB will automatically choose the optimal TLS certificate for each client using Server Name Indication (SNI).
  5. E

    Use a Gateway Load Balancer instead of an Application Load Balancer. Upload all SSL certificates of the domains and use Server Name Indication (SNI).
Xem giải thích

Đáp án

**A và D — Tạo phân phối CloudFront phục vụ HTTPS bằng địa chỉ IP riêng để gắn từng tên miền thay thế với một IP riêng ở mỗi điểm biên; hoặc tải mọi chứng chỉ lên ALB và gắn nhiều chứng chỉ vào cùng một listener bảo mật, để ALB tự chọn chứng chỉ đúng cho mỗi client bằng Server Name Indication (SNI).

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể: phục vụ nhiều tên miền qua HTTPS mà không phải cấp lại chứng chỉ mỗi lần thêm tên miền. | Cách | Thêm tên miền mới cần gì | |---|---| | SNI trên ALB | tải thêm một chứng chỉ, không đụng cái cũ | | IP riêng trên CloudFront | thêm chứng chỉ, không đụng cái cũ | | SAN (phương án B) | CẤP LẠI chứng chỉ mỗi lần | | Wildcard (phương án C) | chỉ phủ tên miền con, không phủ tên miền khác |

⚠ Đây là điểm phân biệt quan trọng nhất của câu này:

SAN: một chứng chỉ liệt kê nhiều tên
    → thêm tên = phát hành lại
      chứng chỉ mới
        ↓
    Đề nói KHÔNG được "re-provision"
    → SAN vi phạm thẳng yêu cầu

⚠ Và wildcard chỉ phủ MỘT cấp tên miền con:

*.congty.com khớp:
    web.congty.com     — CÓ
    api.congty.com     — CÓ
        ↓
    a.b.congty.com     — KHÔNG
    congtykhac.com     — KHÔNG
        ↓
    Đề nói "nhiều TÊN MIỀN" (domains)
    → wildcard không giải được

Gắn nhiều chứng chỉ vào một listener:

aws elbv2 add-listener-certificates \
  --listener-arn <arn-listener> \
  --certificates CertificateArn=<arn-chung-chi-2>

aws elbv2 add-listener-certificates \
  --listener-arn <arn-listener> \
  --certificates CertificateArn=<arn-chung-chi-3>

⚠ SNI hoạt động thế nào:

Client mở kết nối TLS
    → gửi tên miền muốn tới TRONG
      phần bắt tay (ClientHello)
        ↓
    ALB đọc tên đó
    → chọn chứng chỉ phù hợp
    → hoàn tất bắt tay
        ↓
    Một địa chỉ IP phục vụ được
      hàng trăm tên miền

⚠ ALB hỗ trợ tới 25 chứng chỉ mỗi listener theo mặc định:

Một chứng chỉ mặc định
    + tới 25 chứng chỉ SNI bổ sung
        ↓
    Tăng được qua Service Quotas
    → và mỗi chứng chỉ có thể là SAN
      phủ nhiều tên

Ba lợi ích của SNI: | Lợi ích | Chi tiết | |---|---| | MIỄN PHÍ, không tính thêm | | | Thêm tên miền không đụng chứng chỉ cũ | | | Mọi trình duyệt hiện đại đều hỗ trợ | |

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

⚠ Hai đáp án không cùng một hạng về chi phí, và chênh lệch rất lớn.

Cách Chi phí
SNI (phương án D) miễn phí
Dedicated IP (phương án A) khoảng 600 USD/tháng mỗi chứng chỉ 
Dedicated IP là tính năng CÓ THẬT
    → nhưng nó chỉ dành cho việc hỗ trợ
      trình duyệt rất cũ KHÔNG hiểu SNI
        ↓
    Ví dụ: Internet Explorer trên
      Windows XP
    → gần như không còn tồn tại

AWS khuyến nghị rõ ràng dùng SNI trừ khi có ràng buộc đặc biệt:

Với hầu hết mọi tình huống thực tế
    → SNI là lựa chọn đúng
        ↓
    Chọn dedicated IP mà không có
      lý do cụ thể
    → là khoản chi 7.200 USD/năm
      không mang lại gì

Đề chấm cả hai là đúng về mặt kỹ thuật — cả hai đều "phục vụ nhiều tên miền mà không cấp lại chứng chỉ". Nhưng trong một câu hỏi thiết kế thật, chọn dedicated IP mà không nêu lý do sẽ là quyết định sai.

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

  • **B. Thêm Subject Alternative Name (SAN) cho mỗi tên miền vào chứng chỉ — đây là phương án gần nhất và SAN thật sự phủ được nhiều tên miền, nhưng mỗi lần thêm tên miền phải phát hành lại chứng chỉ, đúng điều đề yêu cầu tránh.
  • **C. Dùng chứng chỉ wildcard để xử lý nhiều tên miền con và nhiều tên miền khác nhau — wildcard chỉ phủ một cấp tên miền con của cùng một tên miền.
  • **E. Dùng Gateway Load Balancer thay ALB và tải chứng chỉ lên đó — GWLB làm việc ở tầng 3, nó dùng để chèn thiết bị bảo mật vào đường truyền; không chấm dứt TLS và không nhận chứng chỉ.

Ghi nhớ

⚠ Ba cách phục vụ nhiều tên miền qua HTTPS — bảng phải thuộc: | Cách | Thêm tên miền | Chi phí | |---|---|---| | SNI | thêm chứng chỉ mới | miễn phí | | SAN | phát hành lại chứng chỉ | miễn phí (ACM) | | Dedicated IP (CloudFront) | thêm chứng chỉ | rất đắt |

Từ khoá nhận diện:

"multiple domains without re-provisioning" → SNI "support very old browsers" → dedicated IP "many subdomains of one domain" → wildcard "fixed set of domains" → SAN

⚠ Bốn loại load balancer và tầng hoạt động: | Loại | Tầng | Chấm dứt TLS | |---|---|---| | ALB | 7 | CÓ, hỗ trợ SNI | | NLB | 4 | CÓ (chế độ TLS), hỗ trợ SNI | | GWLB | 3 | KHÔNG | | CLB | 4/7 | có, một chứng chỉ |

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ công khai miễn phí với dịch vụ tích hợp | | | Tự gia hạn nếu xác thực bằng DNS | | | Khoá riêng không xuất được | |

⚠ Chứng chỉ cho CloudFront phải ở us-east-1:

Dù CloudFront là dịch vụ toàn cầu
    → chứng chỉ vẫn phải nằm ở us-east-1
        ↓
    Đây là lỗi cấu hình phổ biến nhất
      với CloudFront

Ba lưu ý về SNI: | Lưu ý | Chi tiết | |---|---| | Tên miền gửi trong ClientHello, chưa mã hoá | | | Trình duyệt hiện đại đều hỗ trợ | | | Encrypted Client Hello (ECH) đang chuẩn hoá | |

⚠ SNI để lộ tên miền cho người nghe lén:

ClientHello chưa được mã hoá
    → ai bắt gói cũng thấy tên miền
      bạn đang truy cập
        ↓
    Đây là cách nhiều hệ thống lọc
      hoạt động
    → và cũng là lý do ECH ra đời

Ba lưu ý về chọn chứng chỉ mặc định: | Lưu ý | Chi tiết | |---|---| | Listener luôn có một chứng chỉ mặc định | | | Client không gửi SNI sẽ nhận chứng chỉ đó | | | Chọn tên miền phổ biến nhất làm mặc định | |

Ba lưu ý về SSL policy: | Lưu ý | Chi tiết | |---|---| | Chọn policy TLS 1.2 trở lên | | | TLS 1.3 nếu client hỗ trợ | | | Rà soát khi có yêu cầu tuân thủ mới | |

Ba lưu ý về theo dõi hết hạn: | Lưu ý | Chi tiết | |---|---| | ACM gửi sự kiện EventBridge trước 45 ngày | | | Chứng chỉ nhập từ ngoài KHÔNG tự gia hạn | | | Giữ bản ghi CNAME xác thực vĩnh viễn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | openssl s_client -servername ten.com -connect alb:443 | | | Thử với nhiều tên miền khác nhau | | | Kiểm chuỗi tin cậy và ngày hết hạn | |

Và một lời khuyên: hãy chọn SNI và chỉ cân nhắc dedicated IP khi có yêu cầu cụ thể về trình duyệt cũ. Hai lựa chọn giải quyết cùng một bài toán, nhưng một cái miễn phí còn cái kia tốn hàng nghìn đô mỗi năm cho một nhóm người dùng gần như không còn tồn tại.

Câu 152 Domain - Design for New Solutions

A company has several financial applications hosted in AWS that uses Amazon S3 buckets to store static data. The Solutions Architect recently discovered that some employees store highly classified data into S3 buckets without proper approval. To mitigate any security risks, the Architect needs to determine all possible S3 objects that contain personally identifiable information (PII) and determine whether the data has been accessed. Due to the sheer volume of data, the Architect must implement an automated solution to accomplish this important task.

Which of the following should the solutions architect implement for this scenario?

  1. A

    Use Amazon GuardDuty to detect personally identifiable information (PII) on the Amazon S3 buckets. Determine if the objects with PII have been recently accessed by tracking the GET API calls in AWS CloudTrail that are used to download these objects.
  2. B

    Install the Amazon Inspector agent on the Amazon S3 buckets. Use AWS CloudTrail to determine if the objects with personally identifiable information (PII) have been recently accessed by tracking the GET API calls that are used to fetch these objects.
  3. C

    Detect personally identifiable information (PII) on the specific S3 buckets using Amazon Athena. Set up Amazon CloudWatch to determine if the objects with PII have been recently accessed by tracking the GET API calls that are used to download these objects.
  4. D

    Enable Amazon Macie on the S3 buckets to automatically classify the data and detect any objects with personally identifiable information (PII). Determine if the objects with PII have been recently accessed by tracking the GET API calls in AWS CloudTrail.
Xem giải thích

Đáp án

**D — Bật Amazon Macie trên các bucket S3 để tự động phân loại dữ liệu và phát hiện object chứa dữ liệu cá nhân; xác định dữ liệu đó có bị truy cập gần đây không bằng cách theo dõi lời gọi API GET trong AWS CloudTrail.

Vì sao đúng

Đề hỏi hai việc, và mỗi dịch vụ lo một việc: | Việc | Dịch vụ | |---|---| | Tìm object nào chứa dữ liệu cá nhân | Macie | | Biết object đó đã bị ai đọc chưa | CloudTrail data event |

⚠ Macie là dịch vụ DUY NHẤT đọc bên trong object S3:

GuardDuty: phân tích LOG hành vi
    → CloudTrail, VPC Flow, DNS
    → không mở object ra đọc
        ↓
    Inspector: quét lỗ hổng phần mềm
      của EC2, ECR, Lambda
    → không đụng tới S3
        ↓
    Macie: MỞ object và đọc nội dung
    → tìm số thẻ, hộ chiếu, số bảo hiểm

⚠ Và CloudTrail phải bật DATA EVENT — đây là chi tiết quyết định:

Management event (bật sẵn):
    `CreateBucket`, `PutBucketPolicy`
        ↓
    Data event (TẮT mặc định, tính phí):
    `GetObject`, `PutObject`, `DeleteObject`
        ↓
    Câu hỏi "ai đã ĐỌC tệp này"
    → bắt buộc phải có data event

Bật data event cho bucket nhạy cảm:

aws cloudtrail put-event-selectors --trail-name trail-chinh \
  --advanced-event-selectors '[{
    "Name": "Doc object bucket tai chinh",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
      {"Field": "resources.ARN", "StartsWith":
        ["arn:aws:s3:::du-lieu-tai-chinh/"]},
      {"Field": "eventName", "Equals": ["GetObject"]}]}]'

⚠ Giới hạn theo tiền tố vì lý do chi phí:

Data event tính phí theo SỐ SỰ KIỆN
    → bucket lưu lượng cao có thể tốn
      hơn cả chi phí lưu trữ
        ↓
    Chỉ bật cho bucket và tiền tố
      thật sự nhạy cảm

Bật Macie và tạo công việc quét:

aws macie2 enable-macie

aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --schedule-frequency '{"dailySchedule":{}}' \
  --name quet-du-lieu-mat \
  --s3-job-definition '{"bucketDefinitions":[
    {"accountId":"111122223333",
     "buckets":["du-lieu-tai-chinh"]}]}'

Truy vấn CloudTrail tìm ai đã đọc:

SELECT userIdentity.arn, requestParameters.key, eventTime
FROM <kho-du-lieu-cloudtrail-lake>
WHERE eventName = 'GetObject'
  AND requestParameters.bucketName = 'du-lieu-tai-chinh'
  AND eventTime > '2026-08-01'
ORDER BY eventTime DESC

Cảnh báo khi Macie phát hiện:

{"source": ["aws.macie"],
 "detail-type": ["Macie Finding"],
 "detail": {"severity": {"description": ["High"]}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tự động, xử lý được khối lượng lớn | | | Macie có bộ nhận diện dữ liệu nhạy cảm sẵn | | | CloudTrail cho bằng chứng ai đã đọc | |

⚠ Và có thể tự định nghĩa mẫu riêng:

aws macie2 create-custom-data-identifier \
  --name ma-khach-hang-noi-bo \
  --regex 'KH-[0-9]{8}' \
  --keywords 'ma khach hang' \
  --maximum-match-distance 50

Dữ liệu nhạy cảm riêng của công ty
    → mẫu tự viết
    → chạy cùng bộ nhận diện có sẵn

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

  • **A. Dùng GuardDuty phát hiện dữ liệu cá nhân trong S3, theo dõi GET bằng CloudTrail — đây là phương án gần nhất và phần CloudTrail hoàn toàn đúng, nhưng GuardDuty phát hiện hành vi đe doạ chứ không quét nội dung object; nó có tính năng S3 Protection nhưng đó là phát hiện truy cập bất thường, không phải phân loại dữ liệu.
  • **B. Cài agent của Inspector lên bucket S3 — Inspector cài agent lên EC2, không có khái niệm agent trên bucket; và nó quét lỗ hổng chứ không quét dữ liệu.
  • **C. Dùng Athena phát hiện dữ liệu cá nhân và CloudWatch theo dõi GET — Athena truy vấn SQL trên dữ liệu có cấu trúc, không tự nhận diện dữ liệu nhạy cảm; và CloudWatch không ghi lời gọi API S3.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật và câu hỏi chúng trả lời — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | Macie | "có dữ liệu nhạy cảm nào trong S3?" | | GuardDuty | "có ai đang tấn công không?" | | Inspector | "có lỗ hổng phần mềm nào?" | | Config | "cấu hình có đúng chuẩn không?" |

Từ khoá nhận diện:

"discover and classify PII in S3" → Macie "who accessed the object" → CloudTrail DATA event "unusual access pattern to S3" → GuardDuty S3 Protection "was the bucket made public" → Config hoặc CloudTrail management event

⚠ Hai loại sự kiện CloudTrail — phải thuộc: | Loại | Ví dụ | Mặc định | |---|---|---| | Management | CreateBucket, RunInstances | BẬT, miễn phí bản đầu | | Data | GetObject, PutItem, Invoke | TẮT, tính phí |

Ba lưu ý về Macie: | Lưu ý | Chi tiết | |---|---| | Tính phí theo GB quét | | | Giới hạn phạm vi bằng tiền tố | | | Có bộ nhận diện sẵn cho nhiều loại dữ liệu | |

Ba nhóm dữ liệu Macie nhận diện: | Nhóm | Ví dụ | |---|---| | Định danh cá nhân | tên, địa chỉ, ngày sinh | | Tài chính | số thẻ, tài khoản ngân hàng | | Thông tin xác thực | khoá riêng, token |

Ba lưu ý về bảo vệ log kiểm toán: | Lưu ý | Chi tiết | |---|---| | Bucket log ở tài khoản RIÊNG | | | Bật Object Lock chế độ compliance | | | Bật log file validation | |

⚠ Tài khoản riêng là biện pháp quan trọng nhất:

Log nằm cùng tài khoản bị xâm nhập
    → kẻ tấn công xoá luôn dấu vết
        ↓
    Tài khoản log riêng, chỉ nhận ghi
    → mất tài khoản chính vẫn còn
      bằng chứng

Ba lưu ý về CloudTrail Lake: | Lưu ý | Chi tiết | |---|---| | Truy vấn SQL sẵn, không cần dựng Athena | | | Giữ tới 10 năm | | | Tính phí theo lượng dữ liệu nạp và quét | |

Ba lưu ý về phòng ngừa: | Lưu ý | Chi tiết | |---|---| | SCP chặn tạo bucket công khai | | | Block Public Access ở mức tài khoản | | | Config rule cảnh báo bucket không mã hoá | |

⚠ Phòng ngừa quan trọng hơn phát hiện:

Macie tìm ra dữ liệu mật đã nằm
  sai chỗ ba tháng
        ↓
    Tốt hơn: chặn nhân viên tạo
      bucket không mã hoá ngay từ đầu
    → và bắt gắn tag phân loại dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặt một tệp thử có mẫu giống số thẻ | | | Xem Macie có phát hiện không | | | Đọc tệp đó rồi tìm trong CloudTrail | |

Và một lời khuyên: hãy bật CloudTrail data event cho bucket nhạy cảm TRƯỚC khi cần tới nó. CloudTrail không dựng lại được quá khứ — nếu chưa bật từ trước, câu hỏi "dữ liệu này đã bị ai đọc chưa" sẽ vĩnh viễn không có câu trả lời.

Câu 153 Domain - Continuous Improvement for Existing Solutions

A company is developing an application that will allow biologists from around the world to submit plant genomic information and share it with other biologists. The application will expect several submissions every minute and will push about 8KB of genomic data every second to the data platform. This data needs to be processed and analyzed to provide meaningful information back to the biologists. The following are the requirements for the data platform:

-The inbound genomic data must be processed near-real-time and provide analytics.

-The received data must be stored in a flexible, parallel, and durable manner.

-After processing the data, the resulting output must be delivered to a data warehouse.

Which of the following options should the Solutions Architect implement to meet the company's requirements?

  1. A

    Create an Amazon Data Firehose stream to deliver the inbound data to an Amazon S3 bucket. Use a Kinesis client to analyze the stored data. For data warehousing, register the S3 bucket on AWS Lake Formation as a data lake. Use Amazon Quicksight to query the data lake.
  2. B

    Create a stream in Amazon Kinesis Data Streams to collect the inbound data. Use a Kinesis client to analyze the genomic data. After processing, use Amazon EMR to save the results to an Amazon Redshift cluster.
  3. C

    Leverage Amazon API Gateway to accept the inbound data and send it to an Amazon SQS queue. Write an AWS Lambda function that will process the messages on the SQS queue. After processing, use Amazon EMR to save the results to an Amazon Redshift cluster.
  4. D

    Store all inbound data files directly to an Amazon S3 bucket. Use Amazon Kinesis with Amazon SQS to analyze the data stored in the S3 bucket. After processing, send the results to an Amazon Redshift cluster.
Xem giải thích

Đáp án

**B — Tạo một luồng trong Amazon Kinesis Data Streams để thu nhận dữ liệu vào, dùng Kinesis client phân tích dữ liệu bộ gen; sau khi xử lý thì dùng Amazon EMR lưu kết quả vào cụm Amazon Redshift.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Xử lý và phân tích gần thời gian thực | Kinesis Data Streams + KCL | | Lưu linh hoạt, song song, bền vững | shard của Kinesis | | Kết quả đưa vào kho dữ liệu | EMR → Redshift |

⚠ Ba từ khoá trong đề chỉ thẳng vào Kinesis Data Streams:

"gần thời gian thực"  → độ trờ dưới 1 giây
"song song"           → nhiều shard, nhiều consumer
"bền vững"            → giữ dữ liệu 24 giờ tới 365 ngày
        ↓
    Firehose không thoả điều kiện đầu
      (tối thiểu 60 giây)
    → và không giữ dữ liệu để phát lại

Đây là lý do phương án A sai.

⚠ Và SQS không phải công cụ cho luồng phân tích:

SQS: một thông điệp, một người đọc
  lấy đi rồi biến mất
        ↓
    Không phát lại được
    → không có nhiều consumer đọc
      cùng dữ liệu
    → không giữ thứ tự theo mẫu

Đây là lý do phương án C yếu hơn.

Tạo luồng:

aws kinesis create-stream --stream-name luong-bo-gen \
  --stream-mode-details StreamMode=ON_DEMAND

⚠ Kiểm tra quy mô trong đề:

8 KB mỗi giây
    → một shard chịu được 1 MB/giây
        ↓
    Một shard thừa sức
    → nhưng chọn ON_DEMAND để không
      phải tính khi lượng gửi tăng

Ghi vào luồng:

import boto3, json
kinesis = boto3.client('kinesis')
kinesis.put_record(
    StreamName='luong-bo-gen',
    Data=json.dumps(du_lieu_gen),
    PartitionKey=ma_nha_sinh_hoc)

⚠ Khoá phân vùng nên chọn theo thứ tự cần giữ:

Cùng một nhà sinh học gửi nhiều mẫu
    → khoá theo mã nhà sinh học
    → các mẫu của họ vào cùng shard
    → giữ đúng thứ tự

Ba đặc tính của Kinesis mà hàng đợi không có:

1. NHIỀU consumer đọc CÙNG dữ liệu
   → phân tích, lưu trữ, máy học
     mỗi cái một luồng riêng
        ↓
2. GIỮ THỨ TỰ trong mỗi shard
        ↓
3. PHÁT LẠI được
   → sửa lỗi thuật toán rồi chạy lại
     dữ liệu cũ

⚠ Điểm thứ ba đặc biệt quan trọng với dữ liệu khoa học:

Thuật toán phân tích bộ gen có lỗi
    → đã xử lý ba ngày dữ liệu sai
        ↓
    Kinesis giữ dữ liệu gốc
    → sửa thuật toán, phát lại từ mốc cũ
        ↓
    Với SQS thì dữ liệu đã biến mất

Đẩy kết quả vào Redshift:

aws emr create-cluster --name phan-tich-bo-gen \
  --release-label emr-7.0.0 \
  --applications Name=Spark \
  --instance-groups \
    InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m6g.xlarge \
    InstanceGroupType=CORE,InstanceCount=2,InstanceType=m6g.xlarge

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phân tích gần thời gian thực | | | Nhiều hệ thống dùng chung một luồng | | | Phát lại được khi thuật toán đổi | |

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

  • **A. Dùng Data Firehose đưa dữ liệu vào S3, dùng Kinesis client phân tích dữ liệu đã lưu, rồi đăng ký bucket làm data lake và truy vấn bằng QuickSight — đây là phương án gần nhất và kiến trúc data lake hoàn toàn hợp lệ, nhưng Firehose có độ trễ tối thiểu 60 giây nên không đạt "gần thời gian thực", và đề đòi kết quả vào kho dữ liệu chứ không phải data lake.
  • **C. Dùng API Gateway + SQS + Lambda, rồi EMR lưu vào Redshift — SQS không giữ dữ liệu để phát lại và không cho nhiều consumer đọc cùng dữ liệu.
  • **D. Lưu thẳng tệp vào S3 rồi dùng "Kinesis với SQS" phân tích dữ liệu trong S3 — Kinesis không đọc dữ liệu từ S3 theo cách này; và lưu tệp rồi xử lý là mô hình theo lô, không phải gần thời gian thực.

Ghi nhớ

⚠ Kinesis Data Streams và Data Firehose — bảng phải thuộc: | Tiêu chí | Data Streams | Data Firehose | |---|---|---| | Độ trễ | dưới 1 giây | tối thiểu 60 giây | | Cần viết consumer | CÓ | không | | Giữ lại và phát lại | CÓ | không | | Nhiều consumer | CÓ | không | | Đích | bất kỳ | S3, Redshift, OpenSearch, Splunk |

Từ khoá nhận diện:

"near real-time, replay, parallel" → Kinesis Data Streams "deliver to S3 with no code" → Firehose "one worker per message" → SQS "data warehouse" → Redshift "data lake" → S3 + Lake Formation + Athena

⚠ Kho dữ liệu và data lake khác nhau: | Tiêu chí | Data warehouse | Data lake | |---|---|---| | Dữ liệu | có cấu trúc, đã xử lý | thô, mọi định dạng | | Schema | khi ghi | khi đọc | | Dịch vụ | Redshift | S3 + Glue + Athena |

Ba lưu ý về shard: | Lưu ý | Chi tiết | |---|---| | Mỗi shard: ghi 1 MB/s, đọc 2 MB/s | | | Khoá phân vùng quyết định shard | | | Khoá lệch tạo shard nóng | |

Ba lưu ý về consumer: | Loại | Đặc điểm | |---|---| | Consumer thường | chia sẻ 2 MB/s mỗi shard | | Enhanced fan-out | 2 MB/s RIÊNG mỗi consumer | | Lambda | đơn giản nhất, không quản KCL |

⚠ Lambda đọc Kinesis có bẫy nghiêm trọng:

Một bản ghi hỏng làm Lambda ném lỗi
    → thử lại cả lô mãi
        ↓
    Shard đó DỪNG HOÀN TOÀN
    → phải đặt `MaximumRetryAttempts`,
      `BisectBatchOnFunctionError` và DLQ

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | IteratorAge | consumer chậm hơn nguồn bao nhiêu | | WriteProvisionedThroughputExceeded | chạm trần ghi | | GetRecords.Success | consumer có đọc được không |

⚠ IteratorAge là chỉ số quan trọng nhất:

Tăng đều đặn → consumer không theo kịp
    → chạm thời gian giữ là MẤT DỮ LIỆU
        ↓
    Đặt cảnh báo ngay từ ngày đầu

Ba lưu ý về EMR: | Lưu ý | Chi tiết | |---|---| | Master và core dùng On-Demand | | | Task node dùng Spot để tiết kiệm | | | Cụm tạm (transient) tự tắt sau khi xong | |

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | COPY từ S3 nhanh hơn INSERT nhiều | | | Chọn distribution key và sort key đúng | | | Serverless cho tải khó đoán | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ lúc gửi tới lúc có kết quả | | | Thử phát lại từ một mốc thời gian cũ | | | Theo dõi IteratorAge khi tải cao | |

Và một lời khuyên: hãy chọn Kinesis Data Streams khi có bất kỳ khả năng nào bạn sẽ muốn xử lý lại dữ liệu cũ. Với dữ liệu khoa học thì thuật toán phân tích luôn được cải tiến — và khả năng chạy lại toàn bộ dữ liệu lịch sử qua phiên bản mới là thứ không có cách nào bù đắp sau khi dữ liệu đã biến mất.

Câu 154 Domain - Continuous Improvement for Existing Solutions

A travel booking company runs its main web application on the AWS cloud. Its trip planner website provides timetables, travel alerts, and other public transportation information for trains, buses, ferries, and trams. The front-end tier is composed of an ALB in front of an Auto Scaling group of Amazon EC2 instances deployed across 3 Availability Zones and a Multi-AZ RDS for its database tier. When there are sporting events and popular concerts to be held in a city, the usage of the trip planner application spikes which causes the application servers to reach utilization of over 90%. The solutions architect must ensure that the website can quickly recover in the event that one of its Availability Zones failed during its peak usage.

Which of the following is the most cost-effective architectural design that should be implemented for this website to maintain high availability?

  1. A To have the most cost-effective architecture, replace all of the Reserved and On-Demand EC2 instances with Spot instances across all Availability Zones. Configure an Auto Scaling group in one of the AZs for scalability.
  2. B Increase the capacity and scaling thresholds of the Auto Scaling group to allow the application servers to scale up across all Availability Zones, which will lower the aggregate utilization of the EC2 instances. Use Reserved Instances to handle the steady-state load and a combination of On-Demand and Spot Instances to process the peak load. When the peak usage is over, scale down the number of the On-Demand and Spot instances.
  3. C

    Deploy six Reserved and Spot EC2 Instances in each of the 3 Availability Zones. In this way, the remaining two Availability Zones can handle the load left behind by the Availability Zone that went down.
  4. D Deploy one On-Demand EC2 instance and two Spot EC2 Instances in each of the 3 Availability Zones. In case that one Availability Zone fails, the remaining two Availability Zones can handle the peak load.
Xem giải thích

Đáp án

**B — Tăng công suất và ngưỡng co giãn của Auto Scaling group để máy chủ mở rộng trên cả ba vùng sẵn sàng, làm giảm mức sử dụng trung bình; dùng Reserved Instance cho tải nền và kết hợp On-Demand cùng Spot cho phần đỉnh; hết đỉnh thì thu hẹp lại.

Vì sao đúng

Đề nêu hai vấn đề và một ràng buộc: | Vấn đề | Cách giải | |---|---| | CPU chạm 90% khi có sự kiện | tăng trần và hạ ngưỡng co giãn | | Phải sống sót khi mất một AZ giữa lúc đỉnh | trải đều ba AZ với công suất dư | | Rẻ nhất | RI cho nền, Spot cho đỉnh |

⚠ Vì sao mức sử dụng 90% là nguy hiểm chứ không phải hiệu quả:

Ba AZ, mỗi AZ chạy 90% CPU
    → mất một AZ
        ↓
    Tải của AZ đó dồn sang hai AZ còn lại
    → mỗi AZ phải gánh thêm 45%
    → vượt 100% → sập dây chuyền
        ↓
    Phải giữ mức đủ thấp để hai AZ
      gánh được tải của ba

⚠ Phép tính công suất N+1 cho ba AZ:

Muốn chịu được mất một AZ
    → hai AZ còn lại phải gánh 100%
        ↓
    Mỗi AZ chạy tối đa 100/3 = 33%
    → nhưng tính cả biên an toàn
    → mục tiêu khoảng 50-60%

Chính sách co giãn theo CPU:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-lich-trinh \
  --policy-name theo-cpu --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 50.0,
    "PredefinedMetricSpecification":
      {"PredefinedMetricType": "ASGAverageCPUUtilization"}}'

⚠ Và kết hợp ba mô hình mua trong một ASG:

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 6
    OnDemandPercentageAboveBaseCapacity: 50
    SpotAllocationStrategy: price-capacity-optimized
  LaunchTemplate:
    Overrides:
      - InstanceType: m6i.large
      - InstanceType: m6a.large
      - InstanceType: m5.large
      - InstanceType: c6i.large

6 máy nền: phủ bằng Reserved Instance
    → phần trên: một nửa On-Demand,
      một nửa Spot
        ↓
    Ổn định cho tải nền
    → rẻ cho phần đỉnh

⚠ Đa dạng loại máy là điều kiện để Spot ổn định:

Chỉ xin m6i.large
    → hết công suất loại đó là mất sạch
        ↓
    Xin nhiều loại tương đương
    → xác suất mất hết cùng lúc rất thấp

⚠ Và với sự kiện biết trước lịch, nên thêm scheduled scaling:

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name asg-lich-trinh \
  --scheduled-action-name truoc-tran-dau \
  --start-time 2026-09-15T10:00:00Z \
  --min-size 30 --desired-capacity 30

Đề nói sự kiện thể thao và hoà nhạc
    → biết trước lịch
        ↓
    Mở rộng TRƯỚC khi tải tới
    → thay vì phản ứng sau

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Sống sót khi mất một AZ giữa lúc đỉnh | | | Chỉ trả tiền công suất đỉnh khi thật sự cần | | | RI giảm mạnh chi phí phần nền | |

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

  • **C. Triển khai sáu instance Reserved và Spot ở mỗi AZ để hai AZ còn lại gánh được tải — đây là phương án gần nhất và phép tính N+1 đúng hướng, nhưng nó cố định số máy: không co giãn theo tải nên vừa lãng phí lúc rảnh vừa có thể thiếu lúc đỉnh bất thường.
  • **D. Triển khai một On-Demand và hai Spot ở mỗi AZ — quá ít máy cho tải đỉnh đã mô tả, và phần lớn công suất nằm trên Spot có thể bị thu hồi đúng lúc bận nhất.
  • **A. Thay toàn bộ bằng Spot và đặt ASG ở một AZ — Spot cho toàn bộ tải sản xuất là rủi ro lớn, và một AZ thì mất luôn khả năng chịu lỗi mà đề yêu cầu.

Ghi nhớ

⚠ Ba mô hình mua và chỗ dùng — bảng phải thuộc: | Mô hình | Chiết khấu | Dùng cho | |---|---|---| | Reserved / Savings Plan | tới 72% | tải nền luôn chạy | | On-Demand | 0 | phần co giãn không gián đoạn được | | Spot | tới 90% | phần chịu được gián đoạn |

Từ khoá nhận diện:

"survive AZ failure at peak" → giữ mức sử dụng đủ thấp "steady baseline" → Reserved Instance "known event schedule" → scheduled scaling "recurring pattern" → predictive scaling

⚠ Vì sao ba AZ rẻ hơn hai AZ ở cùng mức chịu lỗi:

2 AZ: mỗi AZ phải chịu 100% tải
    → tổng công suất 200%
        ↓
    3 AZ: mỗi AZ chịu 50%
    → tổng công suất 150%
    → tiết kiệm 25%

Ba chính sách co giãn: | Chính sách | Dùng khi | |---|---| | Target tracking | mặc định, đơn giản nhất | | Scheduled | đỉnh biết trước theo lịch | | Predictive | có chu kỳ, học từ lịch sử |

⚠ Kết hợp predictive và target tracking là tốt nhất:

Predictive: thêm máy TRƯỚC đỉnh
  dựa trên chu kỳ đã học
        ↓
    Target tracking: xử lý phần
      bất thường ngoài dự đoán
        ↓
    Hai cái bù cho nhau

Ba lưu ý về Spot: | Lưu ý | Chi tiết | |---|---| | Báo trước 2 phút khi thu hồi | | | Đa dạng loại máy giảm rủi ro | | | Capacity Rebalancing thay máy trước khi bị thu | |

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | health-check-type ELB chứ không phải EC2 | | | ALB phải gắn đủ các AZ mà ASG dùng | | | Warm pool rút ngắn thời gian sẵn sàng | |

⚠ Warm pool giải quyết vấn đề "thêm máy quá chậm":

aws autoscaling put-warm-pool \
  --auto-scaling-group-name asg-lich-trinh \
  --min-size 10 --pool-state Stopped

Instance đã khởi động và cấu hình xong
    → ở trạng thái Stopped, tính phí rất ít
        ↓
    Cần mở rộng: bật lên trong ~30 giây
    → thay vì 5 phút khởi động từ đầu

Ba lưu ý về tầng CSDL: | Lưu ý | Chi tiết | |---|---| | Multi-AZ RDS đã có trong đề | | | Cân nhắc read replica cho tải đọc đỉnh | | | Cache trước CSDL giảm tải nhiều nhất | |

Ba lưu ý về đo lường: | Lưu ý | Chi tiết | |---|---| | Xem CPU theo phân vị, không chỉ trung bình | | | Theo dõi HealthyHostCount theo từng AZ | | | Đo thời gian instance mới sẵn sàng phục vụ | |

⚠ Cảnh báo HealthyHostCount phải tách theo AZ:

Con số gộp trông bình thường
    → trong khi một AZ hoàn toàn trống
        ↓
    Chỉ lộ ra khi bạn mất một AZ KHÁC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô phỏng mất một AZ bằng FIS lúc tải cao | | | Đẩy tải xem ASG mở rộng kịp không | | | Kiểm mức sử dụng RI trong Cost Explorer | |

Và một lời khuyên: hãy mô phỏng mất một AZ vào lúc tải cao chứ đừng thử lúc rảnh. Kiến trúc ba AZ nào cũng sống sót khi CPU ở mức 20% — bài kiểm tra thật là liệu hai AZ còn lại có gánh nổi tải của ba hay không, và câu trả lời phụ thuộc hoàn toàn vào mức sử dụng bạn đang chạy.

Câu 155 Domain - Continuous Improvement for Existing Solutions

A visual effects studio has over 40-TB worth of video files stored in the company's on-premises tape library. The tape drives are managed by a Media Asset Management (MAM) solution. The video files contain a variety of footage which includes faces, objects, sceneries, cars, and many others. The company wants to automatically build a metadata library for the video files based on these objects. This will then be used as a catalog for the search feature of the MAM solution. The company already has a catalog of people’s photos and names that appeared on the video footage. The company wants to migrate all the video files of the MAM solution to AWS so a Direct Connect connection was provisioned from the on-premises data center to AWS to facilitate this.

Which of the following is the MOST suitable implementation that will meet the company's requirements?

  1. A

    Create a stream in Amazon Kinesis Video Streams that will ingest the videos from the MAM system and store the videos to an Amazon S3 bucket. Configure the MAM solution to stream the videos into Kinesis Video Streams. Use Amazon Rekognition to build a collection based on the videos by using the catalog of people’s faces and names. Set up a stream consumer that will retrieve the generated metadata and then push it to the MAM solution search catalog.
  2. B

    Provision an AWS Storage Gateway – file gateway appliance on the on-premises data center. Configure the MAM solution to extract the video files from the current tape archives and move them to the file gateway share which is then synced to Amazon S3. Use Amazon Rekognition to build a collection based on the videos by using the catalog of people’s faces and names. Create an AWS Lambda function that will invoke Rekognition to pull the video files from the S3 bucket, retrieve the generated metadata and then push it to the MAM solution search catalog.
  3. C

    Securely upload the files to an Amazon S3 bucket using AWS Transfer for SFTP. Create an Amazon EC2 instance that will run GluonCV libraries to generate metadata information from the video files in the S3 bucket. Store the catalog of people’s faces and names in the Amazon EBS volume to be used by GluonCV. After processing the videos, push the generated metadata to the MAM solution search catalog.
  4. D

    Configure the MAM solution to extract the video files from the current tape archives and move them to an Amazon S3 bucket using AWS DataSync. Use an Amazon SageMaker Jupyter notebook instance to build a collection based on the videos by using the catalog of people’s faces and names. Create an AWS Lambda function that will invoke Amazon SageMaker to pull the video files from the S3 bucket, retrieve the generated metadata, and then push it to the MAM solution search catalog.
Xem giải thích

Đáp án

**B — Dựng AWS Storage Gateway kiểu file gateway tại trung tâm dữ liệu, cấu hình hệ thống MAM trích xuất video từ băng từ và chuyển vào chia sẻ của file gateway để đồng bộ lên S3; dùng Amazon Rekognition dựng collection từ danh mục khuôn mặt và tên có sẵn; và dùng Lambda đẩy metadata sinh ra về danh mục tìm kiếm của MAM.

Vì sao đúng

Đề nêu ba việc, và phương án này khớp từng cái: | Việc | Cách đáp ứng | |---|---| | Chuyển 40 TB video từ băng từ lên AWS | file gateway qua Direct Connect | | Nhận diện khuôn mặt, vật thể, cảnh vật | Rekognition Video | | Đẩy metadata về danh mục MAM | Lambda |

⚠ File gateway là lựa chọn đúng vì hệ thống MAM ghi ra chia sẻ tệp:

MAM đọc băng từ, ghi ra thư mục
    → file gateway lộ ra như một
      chia sẻ NFS/SMB bình thường
        ↓
    MAM không cần biết gì về S3
    → mỗi tệp thành một object S3
    → không phải sửa phần mềm MAM

⚠ Và "mỗi tệp một object" là điều làm phương án này hợp lý:

File gateway: ánh xạ tệp ↔ object 1-1
    → tệp video vào S3 là một object
      hoàn chỉnh
        ↓
    Rekognition đọc thẳng object đó
    → không cần bước ghép nối nào

⚠ Rekognition collection dùng danh mục khuôn mặt có sẵn:

aws rekognition create-collection \
  --collection-id dien-vien-va-nhan-vien

aws rekognition index-faces \
  --collection-id dien-vien-va-nhan-vien \
  --image '{"S3Object":{"Bucket":"anh-nhan-su","Name":"nguoi-01.jpg"}}' \
  --external-image-id "nguyen-van-a"

⚠ external-image-id là chỗ gắn TÊN vào khuôn mặt:

Rekognition không biết tên ai
    → nó chỉ so khớp vector đặc trưng
        ↓
    `external-image-id` là nhãn của bạn
    → khi nhận diện, nó trả lại nhãn này
    → đây là cách dùng "danh mục ảnh
      và tên" mà đề nói tới

Phân tích video:

aws rekognition start-face-search \
  --video '{"S3Object":{"Bucket":"kho-video","Name":"canh-01.mp4"}}' \
  --collection-id dien-vien-va-nhan-vien \
  --notification-channel '{"SNSTopicArn":"<arn>","RoleArn":"<arn>"}'

aws rekognition start-label-detection \
  --video '{"S3Object":{"Bucket":"kho-video","Name":"canh-01.mp4"}}' \
  --notification-channel '{"SNSTopicArn":"<arn>","RoleArn":"<arn>"}'

⚠ Phân tích video là BẤT ĐỒNG BỘ — phải hiểu luồng:

`start-*` trả về JobId ngay
    → xử lý chạy nền
        ↓
    Xong thì đẩy thông báo vào SNS
    → Lambda nhận, gọi `get-*` lấy kết quả
        ↓
    Đẩy metadata về MAM

Lambda thu kết quả:

import boto3, json
rek = boto3.client('rekognition')

def handler(su_kien, ngu_canh):
    tin = json.loads(su_kien['Records'][0]['Sns']['Message'])
    if tin['Status'] != 'SUCCEEDED':
        return
    nhan = rek.get_label_detection(JobId=tin['JobId'])
    day_sang_mam(tin['Video']['S3ObjectName'], nhan['Labels'])

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | MAM không phải sửa gì, chỉ ghi ra thư mục | | | Rekognition có sẵn nhận diện vật thể và cảnh | | | Video gốc nằm trên S3, rẻ và bền | |

⚠ Và nên chuyển video cũ sang lớp lưu trữ rẻ hơn:

{"Rules": [{
  "ID": "video-cu",
  "Status": "Enabled",
  "Transitions": [
    {"Days": 90, "StorageClass": "GLACIER_IR"}]}]}

Video đã phân tích xong
    → metadata nằm trong danh mục MAM
    → video gốc hiếm khi cần lấy lại
        ↓
    Glacier Instant Retrieval:
      rẻ hơn nhiều mà vẫn lấy ngay

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

  • **A. Dùng Kinesis Video Streams để nhận video từ MAM rồi lưu vào S3, dùng Rekognition dựng collection và consumer lấy metadata — đây là phương án gần nhất và Rekognition dùng đúng, nhưng Kinesis Video Streams dành cho luồng video trực tiếp (camera an ninh, thiết bị IoT); đây là kho tệp tĩnh trên băng từ, không phải luồng.
  • **D. Chuyển video lên S3 bằng DataSync, dùng SageMaker notebook dựng collection và Lambda gọi SageMaker phân tích — DataSync đọc được NFS/SMB chứ không đọc thư viện băng từ; và tự huấn luyện mô hình bằng SageMaker là nhiều việc hơn hẳn khi Rekognition đã làm sẵn.
  • **C. Tải tệp lên bằng AWS Transfer for SFTP và chạy GluonCV trên EC2 để sinh metadata — phải tự vận hành máy chủ và tự viết pipeline thị giác máy tính; nhiều việc nhất trong các phương án.

Ghi nhớ

⚠ Bốn kiểu Storage Gateway — bảng phải thuộc: | Kiểu | Giao thức | Dùng cho | |---|---|---| | File Gateway (S3) | NFS, SMB | tệp thành object S3 | | FSx File Gateway | SMB | cache cho FSx for Windows | | Volume Gateway | iSCSI | volume khối | | Tape Gateway | iSCSI VTL | thay thư viện băng từ |

⚠ Chú ý phân biệt với Tape Gateway trong câu này:

Tape Gateway: MÔ PHỎNG thư viện băng
  để phần mềm sao lưu ghi vào
        ↓
    Ở đây MAM ĐỌC băng cũ và ghi
      ra tệp
    → cần chia sẻ tệp
    → File Gateway

Từ khoá nhận diện:

"NFS/SMB share backed by S3" → File Gateway "detect faces, objects in video" → Rekognition "live video stream from cameras" → Kinesis Video Streams "replace tape library for backups" → Tape Gateway

Ba lưu ý về Rekognition: | Lưu ý | Chi tiết | |---|---| | Ảnh: đồng bộ; video: bất đồng bộ | | | Collection lưu vector đặc trưng, không lưu ảnh | | | Tính phí theo phút video phân tích | |

⚠ Collection không lưu ảnh gốc:

`index-faces` trích vector đặc trưng
    → ảnh gốc KHÔNG được lưu lại
        ↓
    Muốn hiển thị ảnh cho người dùng
    → phải tự giữ trong S3

Ba loại phân tích video của Rekognition: | API | Tìm gì | |---|---| | start-label-detection | vật thể, cảnh, hoạt động | | start-face-search | người trong collection | | start-content-moderation | nội dung không phù hợp |

Ba lưu ý về chi phí 40 TB video: | Lưu ý | Chi tiết | |---|---| | Rekognition tính theo PHÚT video | | | 40 TB video là rất nhiều phút | | | Tính thử trước khi chạy toàn bộ | |

⚠ Đây là con số phải ước lượng trước:

Chạy thử vài chục giờ video
    → đo chi phí thực tế mỗi giờ
        ↓
    Nhân với tổng số giờ trong kho
    → có khi lớn hơn nhiều lần
      chi phí lưu trữ

Ba lưu ý về file gateway: | Lưu ý | Chi tiết | |---|---| | Cache cục bộ cho tệp hay dùng | | | Tải lên bất đồng bộ | | | Theo dõi CachePercentDirty | |

⚠ Tải lên bất đồng bộ có hệ quả:

Ghi tệp vào chia sẻ xong
    → chưa chắc đã lên S3
        ↓
    Xoá tệp gốc trên băng ngay
    → rủi ro mất dữ liệu
    → chờ `RefreshCache` xác nhận

Ba lưu ý về Direct Connect cho 40 TB: | Lưu ý | Chi tiết | |---|---| | Đề nói DX đã được cấp — dùng nó | | | Đặt giới hạn băng thông cho gateway | | | Chuyển ngoài giờ làm việc nếu chia sẻ đường | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử một tệp, xem metadata sinh ra | | | Đối chiếu số tệp trên băng và trên S3 | | | Kiểm nhận diện khuôn mặt có đúng người | |

Và một lời khuyên: hãy chạy Rekognition trên một mẫu nhỏ và tính chi phí trước khi xử lý cả kho. Với 40 TB video, phí phân tích tính theo phút có thể vượt xa mọi khoản khác trong dự án — và đó là con số chỉ lộ ra khi bạn nhân nó lên đúng quy mô thật.

Câu 156 Chọn nhiều đáp án Domain - Design for New Solutions

An Amazon partner company plans to host its application on a fleet of Amazon EC2 instances in an Auto Scaling group on a public subnet inside a VPC. A single security group is associated with all the EC2 instances. On a private subnet in the same region, an Amazon Aurora MySQL DB Cluster is created to be accessed by the application. A different security group is associated with the DB Cluster. The solutions architect has been tasked to provide access from the application to the DB Cluster.

Which of the following options is the recommended implementation to meet the application requirements while providing the least-privilege permissions? (Select TWO.)

  1. A

    On the Amazon EC2 instances’ security group, create an outbound rule with the destination as the DB cluster’s security group using the default Aurora port 3306.
  2. B

    On the Amazon EC2 instances’ security group, create an inbound rule with the source as the DB cluster’s security group using the default Aurora port 3306.
  3. C

    To restrict communication in a different subnet, update the inbound Network Access Control List (NACL) of the private subnet to allow access from the public subnet CIDR with default Aurora port 3306.
  4. D

    On the Amazon Aurora cluster’s security group, create an inbound rule with the source as the Amazon EC2 instances’ security group using the default Aurora port 3306.
  5. E

    On the Amazon Aurora cluster’s security group, create an outbound rule with the destination as the Amazon EC2 instances’ security group using the default Aurora port 3306.
  6. F

    To restrict communication in a different subnet, update the outbound Network Access Control List (NACL) of the public subnet to allow access to the private subnet CIDR with the default Aurora port 3306.
Xem giải thích

Đáp án

**A và D — Trên security group của EC2, tạo quy tắc đi ra với đích là security group của cụm CSDL ở cổng 3306; và trên security group của cụm Aurora, tạo quy tắc đi vào với nguồn là security group của EC2 ở cổng 3306.

Vì sao đúng

Đề hỏi cách cấp quyền với đặc quyền tối thiểu, và điểm mấu chốt là chiều của từng quy tắc:

EC2 khởi tạo kết nối TỚI CSDL
    → EC2 cần quy tắc ĐI RA
    → CSDL cần quy tắc ĐI VÀO
        ↓
    Đây là chiều duy nhất đúng

⚠ Đây là lý do B và E sai — chúng đảo ngược chiều: | Phương án | Sai ở đâu | |---|---| | B. EC2 có quy tắc ĐI VÀO từ SG của CSDL | CSDL không khởi tạo kết nối tới EC2 | | E. CSDL có quy tắc ĐI RA tới SG của EC2 | cùng lỗi, ngược chiều |

⚠ Và tham chiếu SG thay vì CIDR là cách viết đúng:

Dùng CIDR của subnet
    → mọi thứ trong subnet đó vào được
    → kể cả máy không liên quan
        ↓
    Tham chiếu SG: chỉ instance
      thuộc nhóm đó
    → và instance mới thêm vào nhóm
      tự động được phép

Quy tắc đi ra trên EC2:

aws ec2 authorize-security-group-egress \
  --group-id sg-ung-dung --protocol tcp --port 3306 \
  --source-group sg-aurora

Quy tắc đi vào trên Aurora:

aws ec2 authorize-security-group-ingress \
  --group-id sg-aurora --protocol tcp --port 3306 \
  --source-group sg-ung-dung

⚠ Nhưng có một chi tiết dễ bỏ sót: quy tắc đi ra MẶC ĐỊNH là mở hết:

Security group mới tạo
    → đi ra: cho phép TẤT CẢ (0.0.0.0/0)
        ↓
    Muốn đặc quyền tối thiểu thật sự
    → phải XOÁ quy tắc mặc định đó
    → rồi mới thêm quy tắc hẹp

aws ec2 revoke-security-group-egress \
  --group-id sg-ung-dung \
  --ip-permissions '[{"IpProtocol":"-1",
    "IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'

⚠ Vì sao KHÔNG cần sửa NACL — điểm phân biệt với C và F:

Security group là STATEFUL
    → cho phép chiều vào thì phản hồi
      tự động được ra
        ↓
    NACL là STATELESS
    → nhưng NACL MẶC ĐỊNH của VPC
      cho phép tất cả
        ↓
    Không cần đụng tới nếu chưa ai
      siết nó lại

⚠ Và siết NACL thêm là bước lùi về khả năng bảo trì:

NACL stateless: phải mở cả dải cổng
  tạm 1024-65535 chiều ngược
        ↓
    Rất dễ tạo lỗi mạng khó lần
    → triệu chứng chỉ là timeout
      không nói gì

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chỉ instance trong nhóm đó vào được CSDL | | | Instance mới tự động được phép | | | Không phụ thuộc IP hay CIDR | |

⚠ Với Aurora còn nên bật xác thực IAM:

aws rds modify-db-cluster \
  --db-cluster-identifier cum-aurora \
  --enable-iam-database-authentication --apply-immediately

Không có mật khẩu tĩnh nào tồn tại
    → EC2 xin token 15 phút bằng vai trò
        ↓
    Kết hợp với security group
    → hai lớp độc lập

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

  • **B. Trên SG của EC2, tạo quy tắc ĐI VÀO với nguồn là SG của CSDL — đây là phương án gần nhất và tham chiếu SG hoàn toàn đúng, nhưng sai chiều: CSDL không bao giờ khởi tạo kết nối tới EC2.
  • **E. Trên SG của Aurora, tạo quy tắc ĐI RA tới SG của EC2 — cùng lỗi ngược chiều.
  • **C và F. Sửa NACL để cho phép giữa hai subnet — NACL mặc định đã cho phép tất cả; sửa nó không cần thiết, và NACL stateless nên rất dễ tạo lỗi khó lần.

Ghi nhớ

⚠ Security group và NACL — bảng phải thuộc: | Tiêu chí | Security group | Network ACL | |---|---|---| | Áp ở | ENI (instance) | subnet | | Trạng thái | STATEFUL | STATELESS | | Quy tắc | chỉ allow | allow và deny | | Xử lý | mọi quy tắc | theo số thứ tự | | Tham chiếu SG khác | CÓ | không |

Từ khoá nhận diện:

"least privilege between tiers" → tham chiếu SG, không dùng CIDR "deny a specific IP" → NACL (SG không có deny) "app connects to database" → egress ở app, ingress ở DB "no static password" → xác thực IAM cho CSDL

⚠ Mẫu phân tầng chuẩn:

sg-alb    : nhận 443 từ Internet
sg-web    : nhận 80 từ sg-alb
sg-ung-dung: nhận 8080 từ sg-web
sg-csdl   : nhận 3306 từ sg-ung-dung
        ↓
    Mỗi tầng chỉ mở cho tầng ngay trước
    → không tầng nào nhận từ Internet
      trừ ALB

Ba lưu ý về stateful: | Lưu ý | Chi tiết | |---|---| | Phản hồi tự động được phép | | | Không cần mở dải cổng tạm | | | Đây là khác biệt lớn nhất với NACL | |

Ba lưu ý về tham chiếu SG: | Lưu ý | Chi tiết | |---|---| | Chỉ trong cùng VPC hoặc VPC đã peering | | | Không dùng được xuyên Region | | | Tự cập nhật khi thêm bớt instance | |

Ba lưu ý về hạn ngạch: | Lưu ý | Chi tiết | |---|---| | 60 quy tắc vào và 60 quy tắc ra mỗi SG | | | 5 SG mỗi ENI (tăng lên 16) | | | Gộp quy tắc bằng prefix list | |

⚠ Prefix list quản lý danh sách CIDR tập trung:

aws ec2 create-managed-prefix-list \
  --prefix-list-name mang-noi-bo \
  --address-family IPv4 --max-entries 20 \
  --entries Cidr=10.0.0.0/16,Description=vpc-chinh

Dùng prefix list trong quy tắc SG
    → sửa danh sách một chỗ
    → mọi SG dùng nó tự cập nhật

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Cluster endpoint cho ghi, reader endpoint cho đọc | | | Cổng mặc định 3306 (MySQL) hoặc 5432 (PostgreSQL) | | | Đặt trong subnet riêng tư | |

Ba lưu ý về gỡ lỗi kết nối: | Công cụ | Việc | |---|---| | Reachability Analyzer | chỉ ra chặng nào chặn | | VPC Flow Logs | thấy REJECT ở đâu | | nc -zv <endpoint> 3306 | kiểm nhanh từ instance |

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Xoá quy tắc đi ra mặc định 0.0.0.0/0 | | | Chỉ mở đúng cổng cần | | | Rà soát định kỳ quy tắc không còn dùng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối từ EC2 tới CSDL — phải thông | | | Kết nối từ instance ngoài nhóm — phải bị chặn | | | Chạy Reachability Analyzer | |

Và một lời khuyên: hãy xoá quy tắc đi ra mặc định trên security group của tầng ứng dụng. Đó là quy tắc cho phép mọi thứ đi ra mọi nơi, nó tồn tại lặng lẽ trên gần như mọi security group, và nó là đường thoát dữ liệu mà không ai nghĩ tới cho tới khi có sự cố.

Câu 157 Domain - Continuous Improvement for Existing Solutions

A financial services company uses hardware security modules (HSMs) to generate encryption master keys. Since the company application logs include personally identifiable information, encryption is required as part of regulatory compliance. The application logs are going to be stored on a central Amazon S3 bucket and should be encrypted at rest. The security team wants to use the company HSMs to generate the key material for encryption on the S3 bucket.

Which of the following options should the solutions architect implement to meet the company’s requirements?

  1. A

    Request to provision an AWS Direct Connect connection from the on-premises data center to AWS VPC. Ensure that the network addresses do not overlap. Apply an Amazon S3 bucket policy on the central logging bucket to allow only encrypted object uploads. Configure the application to generate a unique KMS key for each logging event by querying the on-premises HSMs through the Direct Connection network.
  2. B

    Create a new AWS CloudHSM cluster and set it as the key material source in AWS Key Management Service (KMS) when you generate a new KMS key. Set a 1-year duration for the KMS key automatic key rotation. Apply an Amazon S3 bucket policy on the central logging bucket to require AWS KMS as the encryption source and deny unencrypted object uploads.
  3. C

    Using AWS CLI, create a new KMS key with no key material and use EXTERNAL as the origin of the key. Generate a key from the on-premises HSMs and import it as KMS key using the public key and import token from AWS. Apply an Amazon S3 bucket policy on the central logging bucket to require AWS KMS as the encryption source and deny unencrypted object uploads.
  4. D

    Using AWS CLI, create a new KMS key with AWS-provided key material and use AWS_KMS as the origin of the key. Overwrite this KMS key with a generated key from the on-premises HSMs by using the public key and import token provided by AWS. Set a 1-year duration for the KMS key automatic key rotation. Apply an Amazon S3 bucket policy on the central logging bucket to require AWS KMS as the encryption source and deny unencrypted object uploads.
Xem giải thích

Đáp án

**C — Dùng AWS CLI tạo một khoá KMS không có vật liệu khoá với Origin là EXTERNAL; sinh khoá từ HSM tại chỗ rồi nhập vào KMS bằng public key và import token do AWS cấp; áp bucket policy bắt buộc dùng KMS và từ chối object không mã hoá.

Vì sao đúng

Đề nêu một yêu cầu rất cụ thể: vật liệu khoá phải do HSM của công ty sinh ra, và chỉ một cơ chế làm được điều đó:

KMS bình thường: AWS sinh vật liệu khoá
        ↓
    `Origin: EXTERNAL`: KMS tạo một
      "vỏ khoá" RỖNG
    → bạn sinh vật liệu ở HSM của mình
    → rồi nhập vào
        ↓
    Đây là tính năng Bring Your Own Key

⚠ Quy trình nhập khoá gồm bốn bước:

1. Tạo khoá với Origin=EXTERNAL
2. Xin public key + import token từ AWS
3. Mã hoá vật liệu khoá bằng public key đó
4. Nhập vào KMS kèm token

Bước 1 — tạo vỏ khoá:

aws kms create-key --origin EXTERNAL \
  --description "Khoa nhap tu HSM cong ty"

Bước 2 — lấy tham số nhập:

aws kms get-parameters-for-import --key-id <id> \
  --wrapping-algorithm RSAES_OAEP_SHA_256 \
  --wrapping-key-spec RSA_4096

Bước 3 và 4 — mã hoá rồi nhập:

openssl pkeyutl -encrypt -in vat-lieu-khoa.bin \
  -out vat-lieu-da-boc.bin \
  -inkey public-key.bin -pubin -keyform DER \
  -pkeyopt rsa_padding_mode:oaep \
  -pkeyopt rsa_oaep_md:sha256

aws kms import-key-material --key-id <id> \
  --encrypted-key-material fileb://vat-lieu-da-boc.bin \
  --import-token fileb://import-token.bin \
  --expiration-model KEY_MATERIAL_DOES_NOT_EXPIRE

⚠ Import token có hạn 24 giờ:

Lấy token rồi để đó vài ngày
    → hết hạn, phải lấy lại
        ↓
    Và public key đi kèm cũng phải
      dùng đúng token đó

⚠ Ba hệ quả lớn khi dùng khoá nhập từ ngoài: | Hệ quả | Chi tiết | |---|---| | KHÔNG xoay tự động được | phải nhập vật liệu mới bằng tay | | Bạn phải GIỮ bản sao vật liệu khoá | mất là mất dữ liệu vĩnh viễn | | Xoá vật liệu khỏi KMS được ngay lập tức | dùng như công tắc khẩn cấp |

`delete-imported-key-material` có hiệu lực
  NGAY, không có thời gian chờ
        ↓
    Khác với xoá khoá thường
      (chờ 7-30 ngày)
    → đây vừa là tính năng vừa là rủi ro

Đây chính là lý do phương án B và D sai khi nói tới xoay khoá tự động.

Bucket policy bắt buộc mã hoá:

{"Statement": [
  {"Effect": "Deny", "Principal": "*",
   "Action": "s3:PutObject",
   "Resource": "arn:aws:s3:::log-tap-trung/*",
   "Condition": {"StringNotEquals":
     {"s3:x-amz-server-side-encryption": "aws:kms"}}},
  {"Effect": "Deny", "Principal": "*",
   "Action": "s3:PutObject",
   "Resource": "arn:aws:s3:::log-tap-trung/*",
   "Condition": {"Null":
     {"s3:x-amz-server-side-encryption": "true"}}}]}

⚠ Phải có CẢ HAI câu Deny:

Câu đầu chặn mã hoá SAI loại
    → nhưng request không khai header
      thì `StringNotEquals` không khớp
        ↓
    Câu thứ hai chặn request KHÔNG khai
      header nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Vật liệu khoá do HSM công ty sinh | | | Vẫn dùng được KMS với S3, EBS, RDS | | | Xoá vật liệu là khoá dữ liệu ngay | |

⚠ Và có lựa chọn thứ hai đáng biết: custom key store: | Tiêu chí | Import key material | Custom key store | |---|---|---| | Vật liệu khoá nằm ở | KMS (đã nhập vào) | CloudHSM của bạn | | Chi phí | như khoá KMS thường | cộng chi phí CloudHSM | | Xoay tự động | không | có (xoay trong HSM) |

Đề nói "dùng HSM để SINH vật liệu khoá"
    → nhập vật liệu là đủ và rẻ hơn
        ↓
    Yêu cầu "khoá phải NẰM trong HSM
      của chúng tôi"
    → mới cần custom key store

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

  • **B. Tạo cụm CloudHSM mới và đặt làm nguồn vật liệu khoá khi sinh khoá KMS, đặt xoay tự động một năm — đây là phương án gần nhất và custom key store là cơ chế có thật, nhưng đề nói dùng HSM sẵn có của công ty chứ không phải dựng CloudHSM mới; và khoá trong custom key store không xoay theo cách mô tả.
  • **D. Tạo khoá với vật liệu do AWS cung cấp rồi GHI ĐÈ bằng khoá từ HSM — không có thao tác ghi đè vật liệu khoá; phải tạo khoá với Origin=EXTERNAL ngay từ đầu.
  • **A. Dựng Direct Connect và cho ứng dụng sinh một khoá KMS riêng cho mỗi sự kiện log bằng cách hỏi HSM tại chỗ — tạo một khoá KMS cho mỗi bản ghi log là không khả thi (có hạn ngạch số khoá), và phụ thuộc đường mạng cho mọi thao tác ghi log.

Ghi nhớ

⚠ Bốn nguồn vật liệu khoá của KMS — bảng phải thuộc: | Origin | Vật liệu khoá từ đâu | |---|---| | AWS_KMS | AWS sinh, mặc định | | EXTERNAL | bạn nhập vào (BYOK) | | AWS_CLOUDHSM | custom key store trên CloudHSM | | EXTERNAL_KEY_STORE | HSM bên ngoài AWS (XKS) |

⚠ External Key Store là lựa chọn mới nhất:

Vật liệu khoá KHÔNG BAO GIỜ rời
  HSM của bạn
    → KMS gọi ra ngoài để mã hoá/giải mã
        ↓
    Yêu cầu tuân thủ khắt khe nhất
    → nhưng phải tự vận hành proxy
      và chịu độ trễ mạng

Từ khoá nhận diện:

"key material generated by our HSM" → Origin EXTERNAL (BYOK) "key must never leave our HSM" → External Key Store "dedicated HSM in AWS" → CloudHSM hoặc custom key store "managed, simplest" → KMS thường

Ba lưu ý về khoá nhập từ ngoài: | Lưu ý | Chi tiết | |---|---| | Phải giữ bản sao vật liệu khoá | | | Không xoay tự động | | | Đặt hạn hoặc không hạn cho vật liệu | |

⚠ Đặt hạn cho vật liệu khoá là con dao hai lưỡi:

--expiration-model KEY_MATERIAL_EXPIRES \
--valid-to 2027-08-31T00:00:00Z

Hết hạn: KMS tự xoá vật liệu
    → mọi dữ liệu mã hoá bằng nó
      không giải mã được
        ↓
    Quên nhập lại đúng hạn
    → mất dữ liệu
    → cân nhắc rất kỹ trước khi đặt hạn

Ba lưu ý về key policy: | Lưu ý | Chi tiết | |---|---| | Key policy là nguồn quyền chính | | | Cần cả key policy lẫn IAM policy | | | Đừng khoá mình ra khỏi khoá | |

⚠ Khoá mình ra ngoài là sự cố không cứu được:

Key policy không cho ai quản lý khoá
    → kể cả root
        ↓
    Không sửa được policy
    → phải mở ticket với AWS
    → luôn giữ một principal quản trị

Ba lưu ý về S3 Bucket Key: | Lưu ý | Chi tiết | |---|---| | Giảm tới 99% lời gọi KMS | | | Giảm chi phí và tránh chạm hạn ngạch | | | Nên bật cho bucket lưu lượng cao | |

Ba lưu ý về log tập trung: | Lưu ý | Chi tiết | |---|---| | Bucket log ở tài khoản riêng | | | Bật Object Lock chống xoá | | | Bật log file validation của CloudTrail | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lời gọi KMS | | | Chứng minh được ai giải mã cái gì | | | Lưu bằng chứng quy trình sinh khoá | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải lên object không mã hoá — phải bị từ chối | | | Kiểm KeyState của khoá là Enabled | | | Thử giải mã bằng vai trò không có quyền | |

Và một lời khuyên: hãy có quy trình rõ ràng về nơi cất bản sao vật liệu khoá trước khi nhập nó vào KMS. Với khoá do AWS sinh thì mất khoá là chuyện AWS lo — với khoá bạn tự nhập thì mất bản sao nghĩa là mọi dữ liệu mã hoá bằng nó biến mất vĩnh viễn, và không ai giúp được.

Câu 158 Domain - Design for New Solutions

A national library is planning to store around 50 TB of data containing all their books, articles, and other written materials in AWS. One of the requirements is to have a search feature to enable the users to look for their collection on their dynamic website.

As a Cloud Engineer, what is the most suitable solution that you should implement in AWS to satisfy the needed functionality?

  1. A

    Utilize CloudFormation as the deployment service to deploy the needed AWS resources such as an S3 bucket for storage, OpenSearch to provide the needed search functionality, and an EC2 instance to host their website.
  2. B

    Use AWS CodePipeline as the deployment service to deploy Amazon Kinesis as the storage service and an EC2 instance to serve their website.
  3. C Use Elastic Beanstalk as the deployment service. Deploy the needed AWS resources such as the Multi-AZ RDS for storage and an EC2 instance to host their website.
  4. D Use CodeDeploy as the deployment service to deploy two S3 buckets in which the first one serves as the storage service and the second one for hosting their dynamic website. Use the native search functionality of S3 to satisfy the search feature requirement.
Xem giải thích

Đáp án

**A — Dùng CloudFormation làm công cụ triển khai để dựng các tài nguyên cần thiết: bucket S3 lưu trữ, OpenSearch cung cấp chức năng tìm kiếm, và EC2 chạy website.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này khớp cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Lưu 50 TB sách và tài liệu | S3 — rẻ nhất cho khối lượng này | | Tìm kiếm trên website động | OpenSearch — công cụ tìm kiếm thật |

⚠ Điểm quyết định: S3 KHÔNG có chức năng tìm kiếm nội dung:

S3 chỉ liệt kê object theo TIỀN TỐ khoá
    → `aws s3 ls sach/2026/`
        ↓
    Không tìm được theo NỘI DUNG bên trong
    → không xếp hạng, không tìm gần đúng

Đây là lý do phương án D sai — "chức năng tìm kiếm gốc của S3" là thứ không tồn tại.

⚠ Và kiến trúc đúng là tách bạch hai vai trò:

S3: lưu tệp gốc (PDF, sách quét)
        ↓
    OpenSearch: chỉ đánh chỉ mục
      VĂN BẢN và khoá S3
        ↓
    Người dùng tìm → OpenSearch trả
      danh sách khoá
    → tải tệp gốc từ S3

⚠ Chỉ đưa văn bản vào chỉ mục, KHÔNG đưa tệp:

50 TB tệp vào OpenSearch
    → chi phí khổng lồ
        ↓
    Văn bản trích xuất: vài chục GB
    → cụm nhỏ là đủ
    → đây là điều làm kiến trúc này rẻ

Đánh chỉ mục:

from opensearchpy import OpenSearch
os_client = OpenSearch(hosts=[{'host': diem_cuoi, 'port': 443}],
                       use_ssl=True, http_auth=xac_thuc)
os_client.index(index='tai-lieu', body={
    'khoaS3': khoa,
    'tieuDe': tieu_de,
    'tacGia': tac_gia,
    'namXuatBan': nam,
    'noiDung': van_ban})

Truy vấn có xếp hạng và tô sáng:

{"query": {"multi_match": {
   "query": "lịch sử hàng hải",
   "fields": ["tieuDe^3", "tacGia^2", "noiDung"],
   "fuzziness": "AUTO"}},
 "highlight": {"fields": {"noiDung": {}}}}

⚠ Ba thứ OpenSearch cho mà LIKE trong CSDL không cho:

1. Xếp hạng theo độ liên quan
2. Tìm gần đúng (gõ sai vẫn ra kết quả)
3. Tô sáng đoạn văn khớp
        ↓
    Đây là lý do dùng công cụ tìm kiếm
      chứ không dựng bằng SQL

Trích xuất văn bản từ sách quét:

import boto3
textract = boto3.client('textract')
textract.start_document_text_detection(
    DocumentLocation={'S3Object':
        {'Bucket': 'thu-vien-so', 'Name': khoa}})

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | S3 rẻ nhất cho 50 TB | | | OpenSearch là dịch vụ quản lý | | | CloudFormation dựng lại được toàn bộ | |

⚠ Và vòng đời S3 giảm thêm chi phí cho tài liệu cũ:

{"Rules": [{
  "ID": "tai-lieu-it-doc",
  "Status": "Enabled",
  "Transitions": [
    {"Days": 90, "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}]}]}

Chỉ mục vẫn tìm được tài liệu
    → chỉ khi TẢI mới lấy từ lớp lạnh
    → Glacier Instant Retrieval:
      mili giây, vẫn dùng được

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

  • **C. Dùng Elastic Beanstalk triển khai với Multi-AZ RDS làm nơi lưu trữ và EC2 chạy website — đây là phương án gần nhất và kiến trúc chạy được, nhưng RDS không phải nơi lưu 50 TB tệp (đắt hơn S3 nhiều lần), và tìm kiếm bằng LIKE trong SQL không có xếp hạng hay tìm gần đúng.
  • **B. Dùng CodePipeline triển khai Kinesis làm dịch vụ lưu trữ — Kinesis là luồng dữ liệu tạm, không phải nơi lưu trữ; và CodePipeline là công cụ CI/CD chứ không dựng hạ tầng.
  • **D. Dùng CodeDeploy dựng hai bucket S3, một để lưu và một để chạy website động, dùng chức năng tìm kiếm gốc của S3 — S3 chỉ phục vụ nội dung tĩnh, và không có chức năng tìm kiếm nội dung.

Ghi nhớ

⚠ Bốn cách "tìm kiếm" trên AWS — bảng phải thuộc: | Cách | Dùng cho | |---|---| | OpenSearch Service | tìm toàn văn có xếp hạng | | Amazon Kendra | hỏi bằng ngôn ngữ tự nhiên | | Athena | truy vấn SQL trên dữ liệu S3 | | S3 Select | lọc bên trong MỘT object |

⚠ Kendra đáng cân nhắc cho thư viện tài liệu:

OpenSearch: khớp từ khoá, cần tinh chỉnh
  bộ phân tích ngôn ngữ
        ↓
    Kendra: hiểu câu hỏi tự nhiên
    → "cuốn nào nói về hàng hải thế kỷ 18?"
    → trả về đoạn văn trả lời
        ↓
    Đắt hơn đáng kể

Từ khoá nhận diện:

"search across documents" → OpenSearch hoặc Kendra "store large files cheaply" → S3 "deploy infrastructure as code" → CloudFormation "deploy application code" → CodeDeploy

⚠ Bốn dịch vụ triển khai hay bị lẫn: | Dịch vụ | Việc | |---|---| | CloudFormation | dựng HẠ TẦNG | | CodeDeploy | triển khai MÃ lên máy đã có | | CodePipeline | điều phối quy trình CI/CD | | Elastic Beanstalk | dựng và chạy ỨNG DỤNG |

Ba lưu ý về OpenSearch: | Lưu ý | Chi tiết | |---|---| | Ba master node chuyên dụng cho sản xuất | | | Trải nhiều AZ | | | Đặt trong VPC, đừng để endpoint công khai | |

⚠ Cụm OpenSearch công khai là lỗ hổng nghiêm trọng:

Endpoint công khai + access policy lỏng
    → ai cũng đọc và xoá được chỉ mục
        ↓
    Đây là nguyên nhân của nhiều
      vụ rò rỉ dữ liệu đã công bố

Ba lớp dữ liệu của OpenSearch: | Lớp | Đặc điểm | |---|---| | Hot | SSD, truy vấn nhanh nhất | | UltraWarm | lưu trên S3, rẻ hơn tới 90% | | Cold | chỉ lưu, phải hâm nóng mới truy vấn |

Ba lưu ý về OpenSearch Serverless: | Lưu ý | Chi tiết | |---|---| | Không phải chọn cỡ cụm | | | Tự co giãn theo tải | | | Hợp với tải khó đoán | |

Ba lưu ý về Textract: | Lưu ý | Chi tiết | |---|---| | Đọc được bảng và biểu mẫu | | | Bất đồng bộ cho tài liệu nhiều trang | | | Tính phí theo TRANG — tính trước với 50 TB | |

Ba lưu ý về CloudFormation: | Lưu ý | Chi tiết | |---|---| | Tách template theo tầng | | | Change set trước mọi cập nhật sản xuất | | | DeletionPolicy: Retain cho bucket dữ liệu | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tìm một cụm từ có trong tài liệu | | | Đo thời gian phản hồi truy vấn | | | Kiểm cụm OpenSearch không lộ ra Internet | |

Và một lời khuyên: hãy giữ tệp gốc trong S3 và chỉ đưa văn bản vào chỉ mục tìm kiếm. Trộn lẫn nơi lưu trữ với nơi tìm kiếm là cách chắc chắn nhất biến một hệ thống 50 TB rẻ tiền thành một cụm tìm kiếm đắt đỏ mà không ai dám mở rộng.

Câu 159 Domain - Continuous Improvement for Existing Solutions

A company has a web service portal on which users can perform read and write operations to its semi-structured data. The company wants to refactor the current application and leverage AWS-managed services to have more scalability and higher availability. To ensure optimal user experience, the service is expected to respond to short but significant system load spikes. The service must be highly available and fault-tolerant in the event of a regional AWS failure.

Which of the following options is the suitable solution to meet the company's requirements?

  1. A

    Create a primary Amazon S3 bucket to store the semi-structured data. Enable S3 Cross-Region Replication to sync objects to the backup region. Create an Amazon API Gateway and AWS Lambda-based web service on each region, and set them as the origin for the two Amazon CloudFront distributions. Add the company’s domain as an alternate name on the CloudFront distributions. Create Amazon Route 53 Alias records pointed to each distribution using a failover routing policy.
  2. B

    Create an Amazon Aurora global database to store the semi-structured data in two Regions. Configure Auto Scaling replicas on both regions. Run the web service on an Auto Scaling group of Amazon EC2 instances on both regions using the user data script to download the application code. Place each Auto Scaling group behind their own Application Load Balancer (ALB). Create a single Amazon Route 53 Alias record pointed to each ALB in using a multi-value answer routing policy with health checks enabled.
  3. C

    Use DocumentDB to store the semi-structured data. Create an edge-optimized Amazon API Gateway and AWS Lambda-based web service, and set it as the origin of a global Amazon CloudFront distribution. Add the company’s domain as an alternate name on the CloudFront distribution. Create an Amazon Route 53 Alias record pointed to the CloudFront distribution.
  4. D

    Create an Amazon DynamoDB global table to store the semi-structured data on two Regions. Use on-demand capacity mode to allow DynamoDB scaling. Run the web service on an Auto Scaling Amazon ECS Fargate cluster on each region. Place each Fargate cluster behind their own Application Load Balancer (ALB). Create Amazon Route 53 Alias records pointed to each ALB in using latency routing policy with health checks enabled.
Xem giải thích

Đáp án

**D — Tạo DynamoDB global table lưu dữ liệu bán cấu trúc ở hai Region, dùng chế độ on-demand; chạy dịch vụ web trên cụm ECS Fargate có Auto Scaling ở mỗi Region, mỗi cụm sau một ALB riêng; tạo bản ghi Route 53 Alias trỏ tới từng ALB với định tuyến theo độ trễ và health check.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Dữ liệu bán cấu trúc, đọc và ghi | DynamoDB | | Chịu được đỉnh tải ngắn và mạnh | on-demand, không có trần để chạm | | Sẵn sàng cao, chịu được mất Region | global table + hai Region hoạt động | | Dịch vụ quản lý, ít vận hành | Fargate, không quản máy chủ |

⚠ On-demand là điểm quyết định cho "đỉnh tải ngắn nhưng mạnh":

Provisioned + Auto Scaling
    → phản ứng SAU vài phút
        ↓
    Đỉnh ngắn đã qua trước khi
      công suất kịp tăng
    → yêu cầu bị chặn ngay lúc bận nhất
        ↓
    On-demand: không có công suất
      để chạm trần

⚠ Và global table cho phép GHI ở cả hai Region:

Aurora Global Database (phương án B):
    một Region ghi, Region kia chỉ đọc
        ↓
    DynamoDB global table:
      GHI ĐƯỢC ở mọi Region
    → thật sự active-active

Tạo global table:

aws dynamodb create-table --table-name DuLieuDichVu \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws dynamodb update-table --table-name DuLieuDichVu \
  --replica-updates '[{"Create":{"RegionName":"us-west-2"}}]'

⚠ Global table đòi bật DynamoDB Streams — điều kiện bắt buộc:

Nhân bản dựa trên stream
    → `StreamViewType` phải là
      `NEW_AND_OLD_IMAGES`
        ↓
    Không bật: không tạo replica được

⚠ Và phải hiểu mô hình giải quyết xung đột:

Hai Region cùng ghi một mục
    → "last writer wins" theo dấu
      thời gian
        ↓
    Ghi ở Region A lúc 10:00:00.100
    + ghi ở Region B lúc 10:00:00.200
    → bản của B thắng, bản của A MẤT
        ↓
    Thiết kế sao cho mỗi mục chỉ
      được ghi từ một Region

Định tuyến theo độ trễ:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"CREATE",
    "ResourceRecordSet":{
      "Name":"api.congty.com","Type":"A",
      "SetIdentifier":"us-east-1",
      "Region":"us-east-1",
      "HealthCheckId":"<hc-east>",
      "AliasTarget":{"HostedZoneId":"<zone-alb-east>",
        "DNSName":"<dns-alb-east>",
        "EvaluateTargetHealth":true}}}]}'

⚠ Định tuyến theo độ trễ CÓ health check là active-active có chuyển đổi:

Bình thường: mỗi người dùng đi tới
  Region gần nhất
        ↓
    Một Region hỏng: health check thất bại
    → Route 53 ngừng trả Region đó
    → mọi người đi tới Region còn lại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả hai Region đều phục vụ, không lãng phí | | | Ghi được ở cả hai Region | | | Không có máy chủ nào phải vận hành | |

⚠ Fargate so với EC2 trong bối cảnh này:

EC2 (phương án B): phải quản AMI,
  vá lỗi, user data script
        ↓
    Fargate: chỉ khai task definition
    → co giãn theo task, không theo máy
    → đúng với yêu cầu "ít vận hành"

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

  • **B. Dùng Aurora Global Database với ASG EC2 và ALB ở hai Region, một bản ghi Route 53 Alias — đây là phương án gần nhất và thật sự là kiến trúc đa Region hợp lệ, nhưng Aurora Global chỉ cho ghi ở Region chính; và dùng EC2 với user data script là nhiều việc vận hành hơn Fargate.
  • **A. Dùng S3 với Cross-Region Replication làm nơi lưu dữ liệu bán cấu trúc — S3 là kho object, không phải CSDL cho thao tác đọc/ghi có cấu trúc; và CRR là một chiều, không giải quyết được việc ghi ở cả hai Region.
  • **C. Dùng DocumentDB với API Gateway edge-optimized và một phân phối CloudFront — DocumentDB không có global table; nó chỉ nhân bản trong một Region, nên không chịu được mất Region.

Ghi nhớ

⚠ Bốn CSDL đa Region — bảng phải thuộc: | Dịch vụ | Ghi ở nhiều Region | |---|---| | DynamoDB global table | CÓ, active-active | | Aurora Global Database | KHÔNG, một writer | | RDS cross-region replica | không | | DocumentDB | không có tính năng đa Region |

Từ khoá nhận diện:

"write in multiple Regions" → DynamoDB global table "read in multiple Regions, one writer" → Aurora Global Database "short intense spikes" → on-demand capacity "semi-structured data" → DynamoDB hoặc DocumentDB

⚠ On-demand và provisioned — bảng phải thuộc: | Tiêu chí | On-demand | Provisioned | |---|---|---| | Chuẩn bị trước | không cần | phải đoán công suất | | Đỉnh đột ngột | xử lý được | có thể bị chặn | | Chi phí mỗi đơn vị | cao hơn | thấp hơn | | Hợp với | tải khó đoán | tải ổn định |

Ba lưu ý về global table: | Lưu ý | Chi tiết | |---|---| | Cần bật Streams với NEW_AND_OLD_IMAGES | | | Nhân bản thường dưới một giây | | | Last writer wins khi xung đột | |

⚠ Thiết kế tránh xung đột:

Gắn Region vào khoá phân vùng
  hoặc định tuyến người dùng cố định
  về một Region
        ↓
    Mỗi mục chỉ được ghi từ một nơi
    → không bao giờ có xung đột

Ba lưu ý về Fargate: | Lưu ý | Chi tiết | |---|---| | Không quản máy chủ nào | | | Task role riêng cho quyền ứng dụng | | | Co giãn theo số task, không theo instance | |

⚠ Task role và execution role khác nhau: | Vai trò | Dùng cho | |---|---| | Execution role | kéo image, ghi log — của ECS | | Task role | quyền của chính ứng dụng |

Ba lưu ý về Route 53: | Kiểu | Hành vi | |---|---| | Latency | Region nhanh nhất, cả hai cùng phục vụ | | Failover | chính/phụ, phụ chỉ nhận khi chính hỏng | | Geolocation | theo quốc gia người dùng |

⚠ Health check là phần bắt buộc:

Định tuyến theo độ trễ KHÔNG có
  health check
    → vẫn gửi người dùng tới Region
      đã hỏng
        ↓
    Có health check: tự loại Region hỏng

Ba lưu ý về chi phí đa Region: | Lưu ý | Chi tiết | |---|---| | Global table tính phí ghi nhân bản (rWCU) | | | Truyền dữ liệu giữa Region có phí | | | Hai cụm Fargate là hai khoản chi | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi ở Region A, đọc ở Region B, đo độ trễ | | | Tắt một Region, xem lưu lượng có chuyển | | | Đẩy đỉnh tải xem có bị chặn không | |

Và một lời khuyên: hãy thiết kế sao cho mỗi bản ghi chỉ được ghi từ một Region, dù global table cho phép ghi ở cả hai. Cơ chế "last writer wins" không báo lỗi khi có xung đột — nó chỉ lặng lẽ vứt bỏ một trong hai bản ghi, và bạn sẽ không biết cho tới khi ai đó phát hiện dữ liệu bị mất.

Câu 160 Domain - Design Solutions for Organizational Complexity

A leading insurance firm has several new members in its development team. The solutions architect was instructed to provision access to certain IAM users who perform application development tasks in the VPC. The access should allow the users to create and configure various AWS resources such as deploying Windows EC2 servers. In addition, the users should be able to see the permissions in AWS Organizations to view information about the user's organization, including the master account email and organization limitations.

Which of the following should the solutions architect implement to follow the standard security advice of granting the least privilege?

  1. A

    Attach the AdministratorAccess AWS managed policy to the IAM users.
  2. B

    Create a new IAM role and attach the AdministratorAccess AWS managed policy to it. Assign the IAM Role to the IAM users.
  3. C

    Create a new IAM role and attach the SystemAdministrator AWS managed policy to it. Assign the IAM Role to the IAM users.
  4. D

    Attach the PowerUserAccess AWS managed policy to the IAM users.
Xem giải thích

Đáp án

**D — Gắn chính sách quản lý PowerUserAccess cho các IAM user.

Vì sao đúng

Đề nêu hai nhu cầu, và PowerUserAccess khớp cả hai mà không cấp thừa: | Nhu cầu | PowerUserAccess có | |---|---| | Tạo và cấu hình tài nguyên AWS (EC2 Windows...) | CÓ — toàn quyền dịch vụ | | Xem thông tin tổ chức: email tài khoản chính, giới hạn | CÓ — organizations:Describe* và List* |

⚠ PowerUserAccess được định nghĩa chính xác là:

Cho phép MỌI dịch vụ AWS
    ↓
TRỪ: IAM, Organizations,
     Account Management
    ↓
NGOẠI TRỪ trong ngoại lệ:
  vẫn cho `iam:Get*`, `iam:List*`,
  `organizations:Describe*`,
  `organizations:List*`

Nội dung chính sách:

{"Version": "2012-10-17", "Statement": [
  {"Effect": "Allow", "NotAction": [
     "iam:*", "organizations:*", "account:*"],
   "Resource": "*"},
  {"Effect": "Allow", "Action": [
     "iam:CreateServiceLinkedRole",
     "iam:DeleteServiceLinkedRole",
     "iam:ListRoles",
     "organizations:DescribeOrganization",
     "account:ListRegions",
     "account:GetAccountInformation"],
   "Resource": "*"}]}

⚠ organizations:DescribeOrganization chính là thứ đề nói tới:

aws organizations describe-organization

{"Organization": {
  "Id": "o-abc123",
  "MasterAccountEmail": "quantri@congty.com",
  "FeatureSet": "ALL",
  "AvailablePolicyTypes": [...]}}

Trả về email tài khoản chính
  và thông tin giới hạn tổ chức
    → đúng yêu cầu trong đề

⚠ Và iam:CreateServiceLinkedRole là quyền IAM cần thiết:

Nhiều dịch vụ cần vai trò liên kết
  khi dùng lần đầu
    → ví dụ ASG, ELB, RDS
        ↓
    Không có quyền này
    → tạo tài nguyên thất bại với
      lỗi khó hiểu

⚠ So sánh bốn chính sách quản lý — bảng phải thuộc: | Chính sách | Cho gì | |---|---| | AdministratorAccess | MỌI THỨ, kể cả IAM | | PowerUserAccess | mọi dịch vụ, trừ quản lý IAM | | SystemAdministrator | EC2, CloudWatch, một số dịch vụ hạ tầng | | ReadOnlyAccess | chỉ đọc mọi thứ |

`SystemAdministrator` hẹp hơn nhưng
  KHÔNG có `organizations:Describe*`
        ↓
    Không đáp ứng yêu cầu thứ hai
    → đây là lý do phương án C sai

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đủ quyền phát triển mà không đụng IAM | | | Không tự leo thang quyền được | | | Chính sách quản lý, AWS tự cập nhật | |

⚠ Lợi ích thứ hai là điểm bảo mật quan trọng nhất:

Có `iam:CreateRole` và `iam:AttachRolePolicy`
    → tự tạo vai trò quản trị và
      giả nhận nó
        ↓
    Vô hiệu hoá mọi ranh giới đã dựng
        ↓
    `PowerUserAccess` chặn đúng chỗ đó

⚠ Nhưng nên siết thêm bằng permission boundary:

{"Effect": "Deny",
 "Action": ["ec2:RunInstances"],
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"ForAnyValue:StringNotLike":
   {"ec2:InstanceType": ["t3.*", "m6i.large"]}}}

PowerUser vẫn tạo được instance
  cực đắt
    → chặn loại máy ngoài danh sách

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

  • **C. Tạo vai trò mới và gắn SystemAdministrator — đây là phương án gần nhất và hẹp hơn nên có vẻ đúng nguyên tắc đặc quyền tối thiểu, nhưng chính sách này không bao gồm organizations:Describe*, nên không đáp ứng được yêu cầu xem thông tin tổ chức.
  • **A. Gắn AdministratorAccess cho các IAM user — vi phạm thẳng nguyên tắc đặc quyền tối thiểu; cho luôn quyền quản lý IAM mà đề không yêu cầu.
  • **B. Tạo vai trò với AdministratorAccess rồi gán cho các IAM user — cùng vấn đề trên; việc bọc trong một vai trò không làm quyền hẹp lại.

Ghi nhớ

⚠ Bốn cơ chế giới hạn quyền — bảng phải thuộc: | Cơ chế | Tác dụng | |---|---| | Identity policy | CẤP quyền | | Permission boundary | TRẦN cho một principal | | SCP | TRẦN cho cả tài khoản/OU | | Session policy | trần cho một phiên cụ thể |

Từ khoá nhận diện:

"developers create resources, view org info" → PowerUserAccess "full access including IAM" → AdministratorAccess "read only" → ReadOnlyAccess "security configuration audit" → SecurityAudit

⚠ Ba chính sách chỉ đọc hay bị lẫn: | Chính sách | Phạm vi | |---|---| | ReadOnlyAccess | đọc MỌI THỨ, kể cả nội dung dữ liệu | | SecurityAudit | chỉ đọc cấu hình bảo mật | | ViewOnlyAccess | chỉ liệt kê, không xem chi tiết |

Kiểm toán viên cần xem cấu hình
    → `SecurityAudit`
        ↓
    `ReadOnlyAccess` cho phép đọc luôn
      object trong S3
    → thường là quá rộng

Ba lưu ý về chính sách quản lý: | Lưu ý | Chi tiết | |---|---| | AWS tự cập nhật khi có dịch vụ mới | | | Không sửa được — phải sao chép nếu muốn đổi | | | Dùng làm điểm khởi đầu, rồi thu hẹp | |

⚠ Thu hẹp bằng IAM Access Analyzer:

aws accessanalyzer start-policy-generation \
  --policy-generation-details \
    principalArn=arn:aws:iam::111122223333:role/LapTrinhVien

Phân tích CloudTrail 90 ngày
    → sinh chính sách chỉ gồm
      những API thật sự dùng
        ↓
    Đây là cách chuyển từ PowerUser
      sang đặc quyền tối thiểu thật

Ba lưu ý về IAM user và vai trò: | Lưu ý | Chi tiết | |---|---| | Ưu tiên vai trò hơn IAM user | | | IAM user nghĩa là access key tồn tại lâu | | | IAM Identity Center cho nhân viên | |

⚠ Đề nói "IAM user" nhưng cách hiện đại là khác:

IAM Identity Center + permission set
    → không có IAM user nào
    → credential tạm, hết hạn tự động
        ↓
    Vẫn gán được `PowerUserAccess`
      cho permission set

Ba lưu ý về nhóm: | Lưu ý | Chi tiết | |---|---| | Gắn chính sách cho NHÓM, không cho từng user | | | Thêm người vào nhóm là xong | | | Dễ rà soát ai có quyền gì | |

Ba lưu ý về giám sát quyền: | Lưu ý | Chi tiết | |---|---| | Credential report liệt kê mọi user | | | Access Advisor cho biết dịch vụ nào không dùng | | | Rà soát định kỳ và gỡ quyền thừa | |

aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::111122223333:user/lap-trinh-vien

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử describe-organization — phải thành công | | | Thử iam:CreateUser — phải bị từ chối | | | Thử tạo EC2 Windows — phải thành công | |

Và một lời khuyên: hãy dùng PowerUserAccess làm điểm khởi đầu rồi thu hẹp bằng Access Analyzer sau vài tháng. Chính sách quản lý sẵn giúp đội phát triển bắt đầu ngay, nhưng dữ liệu CloudTrail thật mới cho bạn biết họ thực sự cần những API nào — và con số đó thường nhỏ hơn nhiều so với dự đoán.