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

Tìm thấy 1221 câu.

Câu 301
A company is in the process of implementing AWS Organizations to constrain its developers to use only Amazon EC2, Amazon S3, and Amazon DynamoDB. The developers account resides in a dedicated organizational unit (OU). The solutions architect has implemented the following SCP on the developers account:

When this policy is deployed, IAM users in the developers account are still able to use AWS services that are not listed in the policy.
What should the solutions architect do to eliminate the developers’ ability to use services outside the scope of this policy?
  1. A Create an explicit deny statement for each AWS service that should be constrained.
  2. B Remove the FullAWSAccess SCP from the developers account’s OU.
  3. C Modify the FullAWSAccess SCP to explicitly deny all services.
  4. D Add an explicit deny statement using a wildcard to the end of the SCP.
Xem giải thích

Đáp án

B — Gỡ SCP FullAWSAccess khỏi OU của tài khoản lập trình viên

Vì sao đúng

Điều khiến câu này khó là cách SCP kết hợp với nhau: khi một OU có nhiều SCP, quyền thực tế là giao của tất cả. FullAWSAccess cho phép mọi thứ, nên nếu vẫn còn nó thì việc thêm một SCP chỉ liệt kê EC2, S3, DynamoDB không thu hẹp được gì — giao của "tất cả" và "ba dịch vụ" vẫn là ba dịch vụ... nhưng chỉ khi SCP mới dùng danh sách cho phép. Vấn đề là FullAWSAccess khiến người ta tưởng đã giới hạn trong khi thực tế chưa, nên cách làm chuẩn là gỡ nó ra và chỉ giữ SCP liệt kê đúng ba dịch vụ.

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

  • A. Viết câu Deny cho từng dịch vụ cần chặn — AWS có hàng trăm dịch vụ và liên tục thêm mới; danh sách này không bao giờ đầy đủ.
  • C. Sửa FullAWSAccess thành từ chối tất cả — đây là SCP do AWS quản lý, không sửa được.
  • D. Thêm câu Deny với ký tự đại diện vào cuối — Deny mọi thứ sẽ chặn luôn cả ba dịch vụ muốn cho phép, vì Deny luôn thắng Allow.
Câu 302
A company with several AWS accounts is using AWS Organizations and service control policies (SCPs). An administrator created the following SCP and has attached it to an organizational unit (OU) that contains AWS account 1111-1111-1111:



Developers working in account 1111-1111-1111 complain that they cannot create Amazon S3 buckets. How should the administrator address this problem?
  1. A Add s3:CreateBucket with “Allow” effect to the SCP.
  2. B Remove the account from the OU, and attach the SCP directly to account 1111-1111-1111.
  3. C Instruct the developers to add Amazon S3 permissions to their IAM entities.
  4. D Remove the SCP from account 1111-1111-1111.
Xem giải thích

Đáp án

C — Bảo lập trình viên thêm quyền S3 vào chính sách IAM của họ

Vì sao đúng

Đây là hiểu nhầm phổ biến nhất về SCP: SCP không cấp quyền cho ai cả. Nó chỉ đặt trần quyền tối đa mà tài khoản có thể có. Quyền thực tế là giao của SCP và chính sách IAM.

Vì vậy khi SCP đã cho phép S3 mà lập trình viên vẫn không truy cập được, phần thiếu nằm ở phía IAM — vai hoặc người dùng của họ chưa có chính sách nào cho phép hành động S3.

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

  • A. Thêm s3:CreateBucket với hiệu lực Allow vào SCP — nới trần thêm nữa cũng vô ích khi IAM chưa cấp gì.
  • B. Tách tài khoản khỏi OU rồi gắn SCP trực tiếp — không đổi kết quả, và làm rối cấu trúc tổ chức.
  • D. Gỡ SCP khỏi tài khoản — bỏ luôn hàng rào bảo vệ mà vẫn không cấp quyền nào.

Nhớ nhanh

SCP là trần, IAM là quyền. Không có quyền thì trần cao tới đâu cũng vô nghĩa.

Câu 303
A solutions architect needs to implement a client-side encryption mechanism for objects that will be stored in a new Amazon S3 bucket. The solutions architect created a CMK that is stored in AWS Key Management Service (AWS KMS) for this purpose.

The solutions architect created the following IAM policy and attached it to an IAM role:



During tests, the solutions architect was able to successfully get existing test objects in the S3 bucket. However, attempts to upload a new object resulted in an error message. The error message stated that the action was forbidden.

Which action must the solutions architect add to the IAM policy to meet all the requirements?
  1. A kms:GenerateDataKey
  2. B kms:GetKeyPolicy
  3. C kms:GetPublicKey
  4. D kms:Sign
Xem giải thích

Đáp án

A — kms:GenerateDataKey

Vì sao đúng

Mã hoá phía máy khách dùng mô hình mã hoá phong bì: ứng dụng gọi GenerateDataKey để KMS trả về một khoá dữ liệu ở hai dạng — bản rõ để mã hoá dữ liệu ngay tại chỗ, và bản đã mã hoá để lưu kèm dữ liệu. Ứng dụng dùng bản rõ rồi xoá nó khỏi bộ nhớ; khi cần giải mã thì gửi bản đã mã hoá cho KMS.

Cách này tránh việc gửi cả tệp lớn qua KMS, vốn có giới hạn 4 KB cho mỗi lần mã hoá trực tiếp.

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

  • B. kms:GetKeyPolicy — đọc chính sách của khoá, việc quản trị.
  • C. kms:GetPublicKey — lấy khoá công khai của khoá bất đối xứng; mã hoá phong bì dùng khoá đối xứng.
  • D. kms:Sign — ký số để xác thực tính toàn vẹn, không phải mã hoá.
Câu 304
A solutions architect at a large company needs to set up network security for outbound traffic to the internet from all AWS accounts within an organization in AWS Organizations. The organization has more than 100 AWS accounts, and the accounts route to each other by using a centralized AWS Transit Gateway. Each account has both an internet gateway and a NAT gateway for outbound traffic to the internet. The company deploys resources only into a single AWS Region.

The company needs the ability to add centrally managed rule-based filtering on all outbound traffic to the internet for all AWS accounts in the organization. The peak load of outbound traffic will not exceed 25 Gbps in each Availability Zone.

Which solution meets these requirements?
  1. A Create a new VPC for outbound traffic to the internet. Connect the existing transit gateway to the new VPC. Configure a new NAT gateway. Create an Auto Scaling group of Amazon EC2 instances that run an open-source internet proxy for rule-based filtering across all Availability Zones in the Region. Modify all default routes to point to the proxy's Auto Scaling group.
  2. B Create a new VPC for outbound traffic to the internet. Connect the existing transit gateway to the new VPC. Configure a new NAT gateway. Use an AWS Network Firewall firewall for rule-based filtering. Create Network Firewall endpoints in each Availability Zone. Modify all default routes to point to the Network Firewall endpoints.
  3. C Create an AWS Network Firewall firewall for rule-based filtering in each AWS account. Modify all default routes to point to the Network Firewall firewalls in each account.
  4. D In each AWS account, create an Auto Scaling group of network-optimized Amazon EC2 instances that run an open-source internet proxy for rule-based filtering. Modify all default routes to point to the proxy's Auto Scaling group.
Xem giải thích

Đáp án

B — Tạo một VPC riêng cho lưu lượng đi ra Internet và nối các VPC hiện có vào đó

Vì sao đúng

Đây là mô hình VPC kiểm tra tập trung: tất cả VPC trong tổ chức nối vào một transit gateway, và toàn bộ lưu lượng đi ra Internet được định tuyến qua một VPC riêng có tường lửa. Nhờ vậy luật lọc khai một chỗ cho cả tổ chức, và chi phí NAT Gateway cùng thiết bị tường lửa được dùng chung thay vì nhân lên theo số tài khoản.

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

  • A — cũng dựng VPC riêng nhưng cách nối hoặc định tuyến không đưa được toàn bộ lưu lượng đi qua điểm kiểm tra.
  • C. Dựng Network Firewall ở từng tài khoản — làm được nhưng chi phí và công quản lý nhân lên theo số tài khoản, và luật rất dễ lệch nhau giữa các nơi.
  • D. Tự dựng Auto Scaling group máy chủ proxy ở từng tài khoản — ôm lấy việc vận hành thứ đã có dịch vụ được quản lý làm sẵn.
Câu 305 Design Solutions for Organizational Complexity

A Big Data Analytics company has built a custom data warehousing solution for a large airline by using Amazon Redshift. The solution helps the airline to analyze the international and domestic flight reservations, ticket issuing and boarding information, aircraft operation records, and cargo transportation records. As part of the cost optimizations, the airline now wants to move any historical data (any data older than a year) into S3, as the daily analytical reports consume data for just the last one year. However, the analysts at multiple divisions of the airline want to retain the ability to cross-reference this historical data along with the daily reports. The airline wants to develop a solution with the LEAST amount of effort and MINIMUM cost.

As a Solutions Architect Professional, which option would you recommend to address this use-case?

  1. A

    Set up access to the historical data via Athena. The analytics team can run historical data queries on Athena and continue the daily reporting on Redshift. In case the reports need to be cross-referenced, the analytics team needs to export these in flat files and then do further analysis
  2. B

    Use Glue ETL job to load the S3 based historical data into Redshift. Once the ad-hoc queries are run for the historic data, it can be removed from Redshift
  3. C

    Use Redshift Spectrum to create Redshift cluster tables pointing to the underlying historical data in S3. The analytics team can then query this historical data to cross-reference with the daily reports from Redshift
  4. D

    Use the Redshift COPY command to load the S3 based historical data into Redshift. Once the ad-hoc queries are run for the historic data, it can be removed from Redshift
Xem giải thích

Đáp án

**C — Dùng Redshift Spectrum tạo bảng ngoài trong cụm Redshift trỏ tới dữ liệu lịch sử nằm trên S3; đội phân tích truy vấn dữ liệu đó và đối chiếu chéo với báo cáo hằng ngày trong Redshift.

Vì sao đúng

Đề nêu hai yêu cầu tưởng như mâu thuẫn, và Spectrum giải quyết cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Chuyển dữ liệu cũ ra S3 để giảm chi phí | dữ liệu nằm trên S3, không chiếm node Redshift | | Vẫn đối chiếu chéo với báo cáo hằng ngày | JOIN được giữa bảng Redshift và bảng ngoài |

⚠ Điểm mấu chốt: Spectrum cho phép JOIN dữ liệu S3 với dữ liệu trong cụm:

SELECT d.thang, SUM(m.doanh_thu) AS doanh_thu_nam_nay,
       SUM(l.doanh_thu) AS cung_ky_nam_truoc
FROM dat_cho_hien_tai m                    -- bảng trong Redshift
JOIN spectrum_lich_su.dat_cho l            -- bảng ngoài trên S3
  ON m.ma_chuyen_bay = l.ma_chuyen_bay
JOIN chieu_thoi_gian d ON d.ngay = m.ngay
GROUP BY d.thang;

⚠ Đây là điều Athena KHÔNG làm được:

Athena truy vấn được dữ liệu S3
        ↓
    Nhưng nó KHÔNG nhìn thấy bảng
      nằm trong cụm Redshift
        ↓
    Muốn đối chiếu: phải xuất dữ
      liệu Redshift ra tệp rồi
      ghép tay
        ↓
    Đó chính là điều phương án A
      thừa nhận

Tạo schema ngoài:

CREATE EXTERNAL SCHEMA spectrum_lich_su
FROM DATA CATALOG
DATABASE 'kho_du_lieu_hang_khong'
IAM_ROLE 'arn:aws:iam::111122223333:role/RedshiftSpectrum'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

Tạo bảng ngoài có phân vùng:

CREATE EXTERNAL TABLE spectrum_lich_su.dat_cho (
    ma_chuyen_bay VARCHAR(20),
    ma_hanh_khach VARCHAR(40),
    doanh_thu     DECIMAL(12,2),
    ngay_bay      DATE)
PARTITIONED BY (nam INT, thang INT)
STORED AS PARQUET
LOCATION 's3://kho-hang-khong/dat-cho/';

⚠ Phân vùng là thứ quyết định chi phí Spectrum:

Spectrum tính tiền theo lượng dữ
  liệu QUÉT
        ↓
    Không phân vùng: mọi truy vấn
      quét toàn bộ nhiều năm
        ↓
    Phân vùng theo năm/tháng:
      `WHERE nam = 2025` chỉ quét
      thư mục đó
    → giảm chi phí hàng chục lần

⚠ Và định dạng cột giảm chi phí thêm một bậc nữa: | Định dạng | Lượng quét cho cùng truy vấn | |---|---| | CSV/JSON | toàn bộ tệp | | Parquet/ORC | chỉ các cột được chọn |

Bảng có 50 cột, truy vấn dùng 3 cột
        ↓
    CSV: đọc cả 50 cột
    → Parquet: đọc 3 cột
    → giảm ~94%

⚠ Và vì sao phương án B và D sai — chúng nạp ngược dữ liệu vào cụm:

B dùng Glue ETL nạp vào Redshift
    → D dùng COPY nạp vào Redshift
        ↓
    Cả hai làm cụm phình to trở lại
    → đúng thứ việc lưu trữ ra S3
      định tránh
        ↓
    Và "nạp vào rồi xoá đi sau khi
      chạy xong" là quy trình thủ
      công lặp lại mãi

⚠ Và "ít công sức nhất" là tiêu chí đề nêu rõ: | Phương án | Việc phải làm mỗi lần truy vấn lịch sử | |---|---| | A (Athena) | xuất tệp, ghép tay | | B (Glue ETL) | chạy job nạp, chạy xong xoá | | D (COPY) | chạy COPY, chạy xong xoá | | C (Spectrum) | KHÔNG có gì — chỉ viết SQL |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu lịch sử nằm trên S3, rẻ hơn nhiều | | | JOIN trực tiếp, không phải nạp lại | | | Trả tiền theo lượng quét, không quét thì không tốn | |

⚠ Và Spectrum còn dùng chung Glue Data Catalog với Athena:

Định nghĩa bảng một lần trong
  Glue Data Catalog
        ↓
    Athena, Spectrum, EMR, Glue ETL
      đều dùng được
        ↓
    Không phải khai hai lần

⚠ Và có một mẫu chuyển dữ liệu tự động đáng biết:

UNLOAD ('SELECT * FROM dat_cho WHERE ngay_bay < CURRENT_DATE - 365')
TO 's3://kho-hang-khong/dat-cho/nam=2025/'
IAM_ROLE 'arn:aws:iam::111122223333:role/RedshiftSpectrum'
FORMAT AS PARQUET
PARTITION BY (nam, thang);

DELETE FROM dat_cho WHERE ngay_bay < CURRENT_DATE - 365;

Chạy hằng tháng
    → dữ liệu tự chảy từ cụm ra S3
    → và vẫn truy vấn được qua
      Spectrum

⚠ Và cần chạy ALTER TABLE ADD PARTITION sau khi thêm dữ liệu:

ALTER TABLE spectrum_lich_su.dat_cho
ADD PARTITION (nam=2025, thang=8)
LOCATION 's3://kho-hang-khong/dat-cho/nam=2025/thang=8/';

Thêm tệp vào S3 mà không khai
  phân vùng
        ↓
    Spectrum KHÔNG thấy
    → truy vấn trả về thiếu dữ liệu
      mà không báo lỗi gì

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

  • **A. Truy cập dữ liệu lịch sử qua Athena, chạy báo cáo hằng ngày trên Redshift, khi cần đối chiếu thì xuất ra tệp phẳng rồi phân tích tiếp — đây là phương án gần nhất và Athena thật sự truy vấn được dữ liệu S3 rất rẻ, nhưng nó không JOIN được với bảng trong cụm Redshift, nên mỗi lần đối chiếu là một quy trình thủ công.
  • **B. Dùng Glue ETL nạp dữ liệu lịch sử từ S3 vào Redshift rồi xoá sau khi truy vấn xong — nạp ngược vào cụm là đúng thứ mà việc chuyển ra S3 định tránh.
  • **D. Dùng lệnh COPY nạp dữ liệu lịch sử vào Redshift rồi xoá đi — cùng vấn đề với B, và lặp lại thủ công mỗi lần cần.

Ghi nhớ

⚠ Bốn cách truy vấn dữ liệu trên S3 — bảng phải thuộc: | Công cụ | Đặc điểm | |---|---| | Athena | serverless, không JOIN được với Redshift | | Redshift Spectrum | JOIN được với bảng trong cụm, cần cụm Redshift | | EMR | xử lý lớn, tuỳ biến cao, phải quản cụm | | Glue ETL | biến đổi và nạp, không phải công cụ truy vấn |

Từ khoá nhận diện:

"cross-reference S3 data with Redshift tables" → Spectrum "ad-hoc SQL on S3, no cluster" → Athena "move cold data out of Redshift" → UNLOAD sang S3 + Spectrum "reduce scan cost" → phân vùng + Parquet

Ba lưu ý về Spectrum: | Lưu ý | Chi tiết | |---|---| | Cần một cụm Redshift đang chạy | | | Tính phí theo TB quét, tách khỏi phí cụm | | | Chỉ ĐỌC — không ghi vào bảng ngoài | |

⚠ Và Spectrum chạy trên tầng tính toán riêng của AWS:

Truy vấn Spectrum không chiếm
  node của cụm
        ↓
    Cụm nhỏ vẫn quét được lượng
      dữ liệu rất lớn trên S3
        ↓
    Nhưng bước JOIN và tổng hợp
      cuối vẫn chạy trên cụm

Ba lưu ý về tối ưu chi phí quét: | Cách | Mức giảm | |---|---| | Phân vùng theo cột hay lọc | rất lớn | | Parquet/ORC thay CSV | lớn | | Nén (Snappy, ZSTD) | vừa |

Ba lưu ý về Glue Data Catalog: | Lưu ý | Chi tiết | |---|---| | Dùng chung cho Athena, Spectrum, EMR | | | Crawler tự phát hiện schema và phân vùng | | | Có phiên bản schema | |

⚠ Crawler tự thêm phân vùng mới:

aws glue start-crawler --name crawler-dat-cho

Thay cho việc gõ ALTER TABLE
  ADD PARTITION thủ công
        ↓
    Đặt lịch chạy hằng ngày

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | RA3 tách tính toán khỏi lưu trữ | | | Concurrency Scaling cho đỉnh truy vấn | | | Serverless trả theo lượng dùng | |

⚠ RA3 làm giảm nhu cầu chuyển dữ liệu ra ngoài:

Node DC2: lưu trữ gắn với node
    → hết chỗ phải thêm node
        ↓
    RA3: lưu trữ trên S3 (managed
      storage), tự động phân tầng
    → thêm dung lượng không cần
      thêm node

Ba lưu ý về vòng đời dữ liệu: | Tầng | Nơi lưu | |---|---| | Nóng (1 năm) | bảng trong Redshift | | Ấm (1-5 năm) | S3 Standard + Spectrum | | Lạnh (trên 5 năm) | Glacier, không truy vấn trực tiếp |

Ba lưu ý về quyền: | Lưu ý | Chi tiết | |---|---| | Vai trò IAM gắn vào cụm phải đọc được S3 và Glue | | | Lake Formation quản quyền chi tiết hơn | | | GRANT trên external schema cho từng nhóm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem SVL_S3QUERY_SUMMARY biết đã quét bao nhiêu | | | So chi phí cụm trước và sau khi chuyển dữ liệu | | | Kiểm truy vấn có dùng phân vùng không (partition pruning) | |

Và một lời khuyên: hãy kiểm tra SVL_S3QUERY_SUMMARY để biết truy vấn thật sự quét bao nhiêu dữ liệu. Một truy vấn quên điều kiện phân vùng sẽ chạy bình thường và cho kết quả đúng — chỉ có hoá đơn cuối tháng mới nói cho bạn biết nó đã quét cả năm năm dữ liệu.

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

A retail company has hired you as an AWS Certified Solutions Architect Professional to provide consultancy for managing a serverless application that consists of multiple API gateways, Lambda functions, S3 buckets and DynamoDB tables. The company is getting reports from customers that some of the application components seem to be lagging while loading dynamic images and some are timing out with the "504 Gateway Timeout" error. As part of your investigations to identify the root cause behind this issue, you can confirm that DynamoDB monitoring metrics are at acceptable levels.

Which of the following steps would you recommend to address these application issues? (Select two)

  1. A

    Enable execution logging for the API Gateway. Process and analyze the execution logs in the API Gateway for HTTP errors to determine the root cause of the errors
  2. B

    Process and analyze the VPC Flow Logs to determine if there is packet loss between the Lambda function and S3
  3. C

    Process and analyze the AWS X-Ray traces and analyze HTTP methods to determine the root cause of the HTTP errors
  4. D

    Process and analyze the Amazon CloudWatch Logs for Lambda function to determine processing times for requested images at pre-configured intervals
  5. E

    Enable access logging for the API Gateway. Process and analyze the access logs in the API Gateway for HTTP errors to determine the root cause of the errors
Xem giải thích

Đáp án

**C và D — Xử lý và phân tích AWS X-Ray trace, xem các phương thức HTTP để tìm gốc rễ của lỗi HTTP; và xử lý, phân tích CloudWatch Logs của Lambda để biết thời gian xử lý ảnh theo từng khoảng thời gian.

Vì sao đúng

Đề đã loại trừ sẵn một nghi phạm và mô tả rõ triệu chứng:

Chỉ số DynamoDB ở mức chấp nhận được
        ↓
    → tầng dữ liệu KHÔNG phải nguyên nhân
        ↓
    Triệu chứng: tải ảnh động chậm
      và lỗi "504 Gateway Timeout"

⚠ Lỗi 504 của API Gateway có một nghĩa rất cụ thể:

API Gateway có timeout tích hợp
  tối đa 29 giây
        ↓
    Lambda chạy quá lâu
    → API Gateway bỏ cuộc, trả 504
        ↓
    Nghĩa là: NGHI PHẠM CHÍNH là
      thời gian chạy của Lambda

Đây là lý do phân tích CloudWatch Logs của Lambda (D) là bước bắt buộc.

Tìm hàm chạy lâu bằng Logs Insights:

fields @timestamp, @requestId, @duration, @billedDuration
| filter @type = "REPORT"
| filter @duration > 10000
| stats count() as so_lan,
        avg(@duration) as trung_binh,
        max(@duration) as lau_nhat
        by bin(5m)
| sort lau_nhat desc

⚠ Và dòng REPORT chứa đúng thông tin cần:

REPORT RequestId: abc  Duration: 28450.12 ms
  Billed Duration: 28451 ms  Memory Size: 512 MB
  Max Memory Used: 498 MB  Init Duration: 820.15 ms

`Duration` gần 29 giây → nguyên
  nhân của 504
        ↓
    `Max Memory Used` sát
      `Memory Size` → thiếu bộ nhớ
    → và CPU tỷ lệ theo bộ nhớ
      nên hàm chạy chậm
        ↓
    `Init Duration` → khởi động
      nguội

⚠ Và X-Ray là thứ chỉ ra ĐOẠN NÀO trong hàm chậm:

CloudWatch Logs nói "hàm mất
  28 giây"
        ↓
    X-Ray nói "24 giây trong đó là
      lời gọi tới S3"
        ↓
    Không có X-Ray: biết chậm mà
      không biết chậm ở đâu

Bật X-Ray:

aws lambda update-function-configuration \
  --function-name xu-ly-anh --tracing-config Mode=Active

aws apigateway update-stage --rest-api-id abc123 \
  --stage-name prod \
  --patch-operations op=replace,path=/tracingEnabled,value=true

Đo từng đoạn trong mã:

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()

def xu_ly(event, context):
    with xray_recorder.in_subsegment('tai-anh-goc'):
        anh = s3.get_object(Bucket=KHO, Key=event['khoa'])['Body'].read()
    with xray_recorder.in_subsegment('doi-co-anh'):
        nho = doi_co(anh, 800)
    with xray_recorder.in_subsegment('ghi-ket-qua'):
        s3.put_object(Bucket=KHO_KQ, Key=event['khoa'], Body=nho)

⚠ Và patch_all() tự đo mọi lời gọi AWS SDK và HTTP:

Không phải viết subsegment thủ công
  cho từng lời gọi boto3
        ↓
    X-Ray tự vẽ bản đồ dịch vụ:
      API Gateway → Lambda → S3
        ↓
    Nhìn bản đồ là thấy nút nào đỏ

⚠ Và vì sao hai phương án về log của API Gateway (A, E) thua: | Loại log | Nội dung | |---|---| | Access log | một dòng mỗi yêu cầu: IP, đường dẫn, mã trạng thái, độ trễ | | Execution log | chi tiết từng bước: ánh xạ, uỷ quyền, gọi tích hợp |

Cả hai đều nói "có lỗi 504"
        ↓
    Nhưng đề đã BIẾT là có 504
    → cần biết TẠI SAO
        ↓
    Nguyên nhân nằm trong Lambda,
      không nằm trong API Gateway

⚠ Và execution log còn có một vấn đề riêng:

Execution log ở mức INFO ghi cả
  thân yêu cầu và phản hồi
        ↓
    Rất tốn tiền và có thể ghi
      cả dữ liệu nhạy cảm
        ↓
    Chỉ nên bật tạm khi gỡ lỗi

⚠ Và vì sao phương án B sai:

B phân tích VPC Flow Log tìm mất
  gói tin giữa Lambda và S3
        ↓
    Lambda không đặt trong VPC thì
      KHÔNG có flow log
        ↓
    Và gọi S3 là qua endpoint dịch
      vụ AWS, không phải mạng
      thường bị mất gói
        ↓
    Flow log chỉ ghi ACCEPT/REJECT,
      không ghi mất gói

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Biết chính xác đoạn nào chậm | | | Thấy được xu hướng theo thời gian | | | Không phải đoán mò | |

⚠ Và với việc xử lý ảnh, nguyên nhân hay gặp nhất là bộ nhớ:

Lambda 512 MB xử lý ảnh 20 MP
        ↓
    CPU tỷ lệ theo bộ nhớ
    → 512 MB ≈ 1/3 lõi
        ↓
    Nâng lên 3.008 MB: 2 lõi
    → nhanh hơn nhiều lần
    → và thường RẺ HƠN vì thời
      gian giảm mạnh hơn giá tăng

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

⚠ Bật access log của API Gateway (phương án E) là việc nên làm, chỉ là không trả lời được câu hỏi "tại sao".

$context.requestId $context.status
$context.integrationLatency $context.responseLatency

`integrationLatency` cho biết
  Lambda mất bao lâu
    → `responseLatency` là tổng
        ↓
    Hai số này khoanh vùng được
      vấn đề rất nhanh

Trong thực tế, quy trình gỡ lỗi 504 thường là: đọc access log để biết bao nhiêu phần trăm yêu cầu bị chậm → đọc CloudWatch Logs để biết hàm nào → đọc X-Ray để biết đoạn nào. Đề buộc chọn hai bước cuối, nhưng bước đầu cũng hữu ích.

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

  • **E. Bật access logging cho API Gateway và phân tích lỗi HTTP — đây là phương án gần nhất và access log thật sự nên bật, có cả integrationLatency, nhưng nó chỉ xác nhận điều đã biết là có 504; nguyên nhân nằm bên trong Lambda.
  • **A. Bật execution logging cho API Gateway và phân tích — cùng lý do, thêm vào đó execution log rất tốn kém và có thể ghi cả dữ liệu nhạy cảm.
  • **B. Phân tích VPC Flow Log tìm mất gói giữa Lambda và S3 — Lambda ngoài VPC không sinh flow log, và flow log không ghi việc mất gói.

Ghi nhớ

⚠ Bốn nguồn dữ liệu gỡ lỗi serverless — bảng phải thuộc: | Nguồn | Trả lời câu hỏi | |---|---| | API Gateway access log | bao nhiêu yêu cầu lỗi, chậm bao lâu | | CloudWatch Logs của Lambda | hàm nào chạy lâu, dùng bao nhiêu bộ nhớ | | X-Ray trace | đoạn nào trong hàm chậm | | CloudWatch Metrics | xu hướng, chặn (throttle), lỗi |

Từ khoá nhận diện:

"504 Gateway Timeout" → tích hợp chạy quá 29 giây "find which downstream call is slow" → X-Ray "function duration and memory" → dòng REPORT trong CloudWatch Logs "throttling" → chỉ số Throttles của Lambda

⚠ Ba mã lỗi của API Gateway và nghĩa: | Mã | Nghĩa | |---|---| | 502 Bad Gateway | Lambda trả về định dạng sai, hoặc lỗi | | 504 Gateway Timeout | tích hợp quá 29 giây | | 429 Too Many Requests | vượt hạn mức throttle |

Ba lưu ý về timeout: | Thành phần | Timeout tối đa | |---|---| | API Gateway REST/HTTP | 29 giây | | Lambda | 15 phút | | ALB → Lambda | cấu hình được, tới 4.000 giây |

⚠ Việc chạy lâu không nên đứng sau API Gateway:

Xử lý ảnh mất vài phút
        ↓
    API Gateway không chờ nổi
        ↓
    Mẫu đúng: API trả 202 ngay,
      đẩy việc vào SQS
    → client hỏi trạng thái sau

Ba lưu ý về X-Ray: | Lưu ý | Chi tiết | |---|---| | Lấy mẫu mặc định: 1 yêu cầu/giây + 5% phần còn lại | | | Bật ở cả API Gateway và Lambda mới thấy hết | | | Service map hiển thị nút nào lỗi | |

⚠ Lấy mẫu có thể bỏ sót đúng yêu cầu bị lỗi:

Lỗi hiếm, tỷ lệ lấy mẫu thấp
        ↓
    Không có trace nào của yêu cầu
      lỗi
        ↓
    Tăng tỷ lệ lấy mẫu tạm thời
      khi đang điều tra

Ba lưu ý về Logs Insights: | Lưu ý | Chi tiết | |---|---| | Truy vấn được nhiều log group cùng lúc | | | Tính tiền theo lượng dữ liệu quét | | | Lưu truy vấn hay dùng lại | |

Ba lưu ý về tối ưu Lambda: | Lưu ý | Chi tiết | |---|---| | Tăng bộ nhớ thường làm RẺ hơn | | | Lambda Power Tuning tìm điểm tối ưu | | | Tái dùng kết nối ngoài handler | |

⚠ Khởi tạo ngoài handler chạy một lần mỗi môi trường:

import boto3
s3 = boto3.client('s3')   # ngoài handler — dùng lại

def xu_ly(event, context):
    ...                    # trong handler — chạy mỗi lần

Ba lưu ý về khởi động nguội: | Lưu ý | Chi tiết | |---|---| | Init Duration trong dòng REPORT | | | Provisioned concurrency loại bỏ hẳn | | | Gói triển khai nhỏ khởi động nhanh hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So integrationLatency với Duration của Lambda | | | Xem service map của X-Ray tìm nút đỏ | | | Kiểm Max Memory Used có sát trần không | |

Và một lời khuyên: hãy so Max Memory Used với Memory Size trước khi đi tìm nguyên nhân phức tạp. Với hàm xử lý ảnh, phần lớn ca "chậm rồi timeout" hoá ra chỉ là hàm được cấp quá ít bộ nhớ — và vì CPU của Lambda tỷ lệ theo bộ nhớ, việc nâng con số đó thường vừa nhanh hơn vừa rẻ hơn.

Câu 307 Design Solutions for Organizational Complexity

An e-commerce company wants to rollout and test a blue-green deployment for its global application in the next couple of days. Most of the customers use mobile phones which are prone to DNS caching. The company has only two days left before the big sale will be launched.

As a Solutions Architect Professional, which of the following options would you suggest to test the deployment on as many users as possible in the given time frame?

  1. A

    Use Elastic Load Balancer to distribute traffic across deployments
  2. B

    Use Route 53 weighted routing to spread traffic across different deployments
  3. C

    Use AWS Global Accelerator to distribute a portion of traffic to a particular deployment
  4. D

    Use AWS CodeDeploy deployment options to choose the right deployment
Xem giải thích

Đáp án

**C — Dùng AWS Global Accelerator để chuyển một phần lưu lượng sang bản triển khai mới.

Vì sao đúng

Đề nêu một ràng buộc rất cụ thể và đó là chìa khoá:

Phần lớn khách hàng dùng điện thoại
        ↓
    Điện thoại HAY CACHE DNS
        ↓
    Chỉ còn hai ngày
    → không có thời gian chờ TTL
      hết hạn

⚠ Đây là lý do phương án B (Route 53 weighted) thất bại:

Route 53 điều khiển lưu lượng bằng
  cách trả về IP khác nhau
        ↓
    Client đã cache bản ghi DNS
    → vẫn gọi IP cũ
        ↓
    Đổi trọng số không có tác dụng
      tức thì
    → và một số client cache lâu
      hơn TTL rất nhiều

⚠ Và Global Accelerator hoạt động hoàn toàn khác:

Global Accelerator cấp HAI IP
  TĨNH anycast
        ↓
    IP đó KHÔNG BAO GIỜ đổi
        ↓
    Chuyển lưu lượng bằng cách đổi
      ĐÍCH ĐẾN phía sau cùng một IP
    → cache DNS trở nên vô hại

Client → 75.2.x.x (không đổi)
              ↓
      Global Accelerator
              ↓
   ┌──────────┴──────────┐
   ↓                     ↓
Bản xanh 90%        Bản mới 10%

Đặt tỷ lệ lưu lượng:

aws globalaccelerator update-endpoint-group \
  --endpoint-group-arn <arn-nhom> \
  --traffic-dial-percentage 10

⚠ Và trọng số từng endpoint cho phép chia nhỏ hơn nữa:

aws globalaccelerator update-endpoint-group \
  --endpoint-group-arn <arn-nhom> \
  --endpoint-configurations \
    EndpointId=<arn-alb-xanh>,Weight=225 \
    EndpointId=<arn-alb-luc>,Weight=25

⚠ Và thay đổi có hiệu lực trong vài giây: | Cơ chế | Thời gian có hiệu lực | |---|---| | Global Accelerator traffic dial | vài giây | | Route 53 weighted | theo TTL, thực tế lâu hơn | | ALB weighted target group | vài giây, nhưng chỉ trong một Region |

⚠ Và quay lui cũng nhanh y như vậy:

Bản mới có vấn đề
    → đặt traffic dial về 0
        ↓
    Vài giây sau, mọi lưu lượng
      quay về bản cũ
        ↓
    Với Route 53: phải chờ TTL của
      từng client

⚠ Và vì sao phương án A (ELB) không đủ:

Đề nói ứng dụng TOÀN CẦU
        ↓
    Một ELB chỉ phục vụ trong MỘT
      Region
        ↓
    Không phân phối được lưu lượng
      giữa các Region

Nhưng trong MỘT Region, ALB làm
  được việc này rất tốt:
    → weighted target group

aws elbv2 modify-listener --listener-arn <arn> \
  --default-actions '[{"Type":"forward","ForwardConfig":
    {"TargetGroups":[
      {"TargetGroupArn":"<tg-xanh>","Weight":90},
      {"TargetGroupArn":"<tg-luc>","Weight":10}]}}]'

⚠ Và vì sao phương án D (CodeDeploy) không trả lời đúng câu hỏi:

CodeDeploy có kiểu triển khai
  blue/green và canary
        ↓
    Nhưng nó điều khiển lưu lượng
      THÔNG QUA ALB hoặc Lambda alias
        ↓
    Với ứng dụng toàn cầu nhiều
      Region, nó không giải quyết
      vấn đề cache DNS

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | IP tĩnh, miễn nhiễm với cache DNS | | | Đổi tỷ lệ có hiệu lực trong vài giây | | | Quay lui tức thì | |

⚠ Và một lợi ích phụ đáng kể: giảm độ trễ:

Client kết nối tới điểm biên AWS
  gần nhất
        ↓
    Từ đó đi trên MẠNG XƯƠNG SỐNG
      của AWS tới Region
        ↓
    Không đi qua Internet công cộng
    → độ trễ ổn định hơn nhiều

⚠ Và Global Accelerator tự chuyển đổi khi một Region hỏng:

Kiểm tra sức khoẻ endpoint
        ↓
    Endpoint hỏng → chuyển lưu lượng
      sang nhóm khác trong vài giây
        ↓
    Route 53 health check cũng làm
      được, nhưng lại phụ thuộc TTL

⚠ Nhưng cần lưu ý về chi phí:

Global Accelerator: phí cố định
  theo giờ + phí truyền dữ liệu
        ↓
    Đắt hơn Route 53 đáng kể
        ↓
    Với một đợt thử nghiệm hai ngày
      thì không đáng kể
    → dùng lâu dài thì phải tính

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

  • **B. Dùng Route 53 weighted routing chia lưu lượng giữa các bản triển khai — đây là phương án gần nhất và là cách chuẩn để làm canary khi có thời gian, nhưng đề nói rõ khách hàng dùng điện thoại hay cache DNS và chỉ còn hai ngày, nên việc đổi trọng số sẽ không tới được phần lớn người dùng kịp thời.
  • **A. Dùng Elastic Load Balancer phân phối giữa các bản triển khai — ELB chỉ hoạt động trong một Region, không phục vụ được ứng dụng toàn cầu.
  • **D. Dùng các tuỳ chọn triển khai của AWS CodeDeploy — CodeDeploy điều khiển lưu lượng qua ALB hoặc Lambda alias, không giải quyết vấn đề cache DNS ở quy mô nhiều Region.

Ghi nhớ

⚠ Bốn cách chia lưu lượng cho triển khai canary — bảng phải thuộc: | Cách | Phạm vi | Phụ thuộc DNS | |---|---|---| | Global Accelerator traffic dial | nhiều Region | KHÔNG | | Route 53 weighted | nhiều Region | CÓ | | ALB weighted target group | một Region | không | | Lambda alias weighted | một hàm | không |

Từ khoá nhận diện:

"DNS caching, need traffic shift now" → Global Accelerator "static IP addresses" → Global Accelerator hoặc NLB "canary within one Region" → ALB weighted target group "gradual Lambda rollout" → alias với weight

⚠ Global Accelerator và CloudFront — hai dịch vụ khác nhau: | Tiêu chí | Global Accelerator | CloudFront | |---|---|---| | Cache | KHÔNG | CÓ | | Giao thức | TCP, UDP | HTTP/HTTPS | | IP tĩnh | CÓ, anycast | không | | Hợp với | API, game, VoIP | nội dung web tĩnh và động |

Ba lưu ý về Global Accelerator: | Lưu ý | Chi tiết | |---|---| | Hai IP tĩnh từ hai vùng mạng khác nhau | | | Traffic dial 0-100% mỗi nhóm endpoint | | | Client affinity giữ người dùng ở cùng endpoint | |

⚠ Client affinity quan trọng khi ứng dụng có trạng thái:

`ClientAffinity: SOURCE_IP`
        ↓
    Cùng một IP nguồn luôn tới
      cùng endpoint
        ↓
    Không có: mỗi kết nối có thể
      rơi vào bản khác nhau
    → người dùng thấy giao diện
      nhảy qua nhảy lại

Ba lưu ý về triển khai blue/green: | Lưu ý | Chi tiết | |---|---| | Schema CSDL phải tương thích cả hai bản | | | Có sẵn tiêu chí quyết định quay lui | | | Theo dõi tỷ lệ lỗi tách riêng từng bản | |

⚠ Tương thích schema là yêu cầu khắt khe nhất:

Bản mới thêm cột NOT NULL
        ↓
    Bản cũ ghi thiếu cột đó → lỗi
        ↓
    Quy tắc: mở rộng trước, thu hẹp
      sau
    → thêm cột nullable, triển khai
      mã, rồi mới siết ràng buộc

Ba lưu ý về DNS TTL: | Lưu ý | Chi tiết | |---|---| | Hạ TTL nhiều ngày TRƯỚC khi cần đổi | | | Nhiều client bỏ qua TTL | | | Ứng dụng di động thường cache lâu nhất | |

Ba lưu ý về giám sát canary: | Chỉ số | Ý nghĩa | |---|---| | Tỷ lệ lỗi 5xx theo target group | bản mới có hỏng không | | Độ trễ p99 theo bản | bản mới có chậm hơn không | | Chỉ số nghiệp vụ | tỷ lệ chuyển đổi, đơn hàng |

⚠ Chỉ số nghiệp vụ mới là thứ quyết định:

Bản mới không có lỗi kỹ thuật nào
        ↓
    Nhưng tỷ lệ đặt hàng giảm 15%
        ↓
    Đó vẫn là lý do quay lui
    → chỉ số kỹ thuật không đủ

Ba lưu ý về quay lui: | Lưu ý | Chi tiết | |---|---| | Đặt ngưỡng tự động quay lui trước | | | Thử quy trình quay lui trước khi cần | | | Giữ bản cũ chạy tới khi chắc chắn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đổi traffic dial và đo sau bao lâu thấy hiệu lực | | | So chỉ số hai bản song song | | | Thử quay lui về 0% và bấm giờ | |

Và một lời khuyên: hãy hạ TTL của DNS xuống 60 giây từ nhiều ngày trước mọi đợt triển khai lớn, ngay cả khi đã dùng Global Accelerator. Cache DNS là thứ không ai kiểm soát được và luôn tệ hơn dự tính — hạ TTL sớm là biện pháp rẻ nhất để giữ cho mình một đường lui.

Câu 308 Continuous Improvement for Existing Solutions

A retail company recently saw a huge spike in its monthly AWS spend. Upon further investigation, it was found that some developers had accidentally launched Amazon RDS instances in unexpected Regions. The company has hired you as an AWS Certified Solutions Architect Professional to establish best practices around least privileges for developers and control access to on-premises as well as AWS Cloud resources using Active Directory. The company has mandated you to institute a mechanism to control costs by restricting the level of access that developers have to the AWS Management Console without impacting their productivity. The company would also like to allow developers to launch RDS instances only in us-east-1 Region without limiting access to other services in any Region.

How can you help the company achieve the new security mandate while minimizing the operational burden on the DevOps team?

  1. A

    Configure SAML-based authentication tied to an IAM role that has a PowerUserAccess managed policy and a customer-managed policy that denies all the developers access to any AWS services except AWS Service Catalog. Within AWS Service Catalog, create a product containing only RDS service in us-east-1 region
  2. B

    Set up an IAM user for each developer and add them to the developer IAM group that has the PowerUserAccess managed policy attached to it. Attach a customer-managed policy that allows the developers access to RDS only in us-east-1 Region
  3. C

    Configure SAML-based authentication tied to an IAM role that has the AdministrativeAccess managed policy attached to it. Attach a customer-managed policy that denies access to RDS in any AWS Region except us-east-1
  4. D

    Configure SAML-based authentication tied to an IAM role that has the PowerUserAccess managed policy attached to it. Attach a customer-managed policy that denies access to RDS in any AWS Region except us-east-1
Xem giải thích

Đáp án

**D — Dùng xác thực SAML gắn với một IAM role có chính sách quản lý PowerUserAccess, kèm một chính sách tự quản từ chối truy cập RDS ở mọi Region trừ us-east-1.

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ùng Active Directory quản lý truy cập | xác thực SAML | | Quyền tối thiểu, không cản trở năng suất | PowerUserAccess | | RDS chỉ ở us-east-1 | chính sách Deny có điều kiện Region | | Không giới hạn dịch vụ khác ở Region khác | Deny chỉ nhắm RDS |

⚠ Điểm mấu chốt thứ nhất: SAML nghĩa là không có IAM user nào:

IAM user cho từng lập trình viên
  (phương án B)
    → phải tạo, phải xoá khi
      nghỉ việc
        ↓
    Người nghỉ mà quên xoá
    → tài khoản sống mãi
        ↓
    SAML: danh tính nằm ở Active
      Directory
    → khoá AD là mất quyền AWS ngay

Đây là lý do phương án B thua dù chính sách quyền của nó cũng gần đúng.

⚠ Điểm mấu chốt thứ hai: PowerUserAccess chứ không phải AdministratorAccess: | Chính sách | Cho phép | |---|---| | AdministratorAccess | MỌI thứ, kể cả IAM | | PowerUserAccess | mọi dịch vụ TRỪ quản lý IAM và Organizations |

Lập trình viên có
  AdministratorAccess
    → tự sửa được chính sách
      giới hạn của chính mình
        ↓
    Mọi ràng buộc trở nên vô nghĩa

Đây là lý do phương án C sai — nó dùng AdministratorAccess.

Chính sách chặn RDS ngoài us-east-1:

{"Version": "2012-10-17", "Statement": [{
  "Sid": "CamRDSNgoaiUsEast1",
  "Effect": "Deny",
  "Action": "rds:*",
  "Resource": "*",
  "Condition": {"StringNotEquals": {
    "aws:RequestedRegion": "us-east-1"}}}]}

⚠ aws:RequestedRegion là khoá điều kiện phải nhớ:

Nó là Region mà LỜI GỌI API nhắm tới
        ↓
    Không phải Region của người gọi
    → không phải Region của tài
      nguyên đã có
        ↓
    Chặn được ở đúng thời điểm tạo

⚠ Và Deny tường minh luôn thắng — đây là lý do mẫu này hoạt động:

`PowerUserAccess` cho phép rds:*
        ↓
    Chính sách tự quản Deny rds:*
      ngoài us-east-1
        ↓
    Deny thắng
    → RDS chỉ dùng được ở us-east-1
    → mọi dịch vụ khác không đụng tới

⚠ Và vì sao phương án A (Service Catalog) quá hạn chế:

A từ chối MỌI dịch vụ trừ
  Service Catalog
        ↓
    Lập trình viên chỉ khởi động
      được sản phẩm có sẵn trong
      danh mục
        ↓
    Đề nói rõ: "không ảnh hưởng
      năng suất"
    → và "không giới hạn dịch vụ
      khác ở Region nào"

⚠ Nhưng Service Catalog là công cụ tốt cho mục đích khác:

Muốn lập trình viên chỉ dựng
  hạ tầng theo khuôn chuẩn
        ↓
    Service Catalog rất hợp
    → nhưng đó là bài toán khác
      với bài toán trong đề

Thiết lập SAML:

aws iam create-saml-provider \
  --name ActiveDirectoryCongTy \
  --saml-metadata-document file://sieu-du-lieu-idp.xml

Trust policy của vai trò:

{"Effect": "Allow",
 "Principal": {"Federated":
   "arn:aws:iam::111122223333:saml-provider/ActiveDirectoryCongTy"},
 "Action": "sts:AssumeRoleWithSAML",
 "Condition": {"StringEquals": {
   "SAML:aud": "https://signin.aws.amazon.com/saml"}}}

⚠ Và SCP là lớp bổ trợ nên có thêm:

{"Effect": "Deny", "Action": "rds:*", "Resource": "*",
 "Condition": {"StringNotEquals": {
   "aws:RequestedRegion": "us-east-1"}}}

Chính sách IAM: quản trị viên tài
  khoản gỡ được
        ↓
    SCP: chỉ tài khoản quản lý gỡ
      được
    → phòng thủ theo lớp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Danh tính quản lý một chỗ ở AD | | | Credential tạm, tự hết hạn | | | Giới hạn hẹp đúng vấn đề chi phí | |

⚠ Và IAM Identity Center là cách hiện đại hơn để làm việc này:

IAM Identity Center kết nối với AD
  hoặc IdP bất kỳ
        ↓
    Quản lý permission set tập trung
    → gán cho nhiều tài khoản một lúc
        ↓
    Có cổng đăng nhập sẵn
    → không phải tự dựng liên kết SAML
      cho từng tài khoản

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

  • **B. Tạo IAM user cho từng lập trình viên, thêm vào nhóm có PowerUserAccess, kèm chính sách chỉ cho phép RDS ở us-east-1 — đây là phương án gần nhất và chính sách quyền hoàn toàn hợp lý, nhưng đề yêu cầu dùng Active Directory quản lý truy cập, mà IAM user là danh tính riêng phải tự quản vòng đời.
  • **C. SAML gắn với vai trò có AdministratorAccess kèm Deny RDS ngoài us-east-1 — quyền quản trị cho phép sửa chính sách IAM, nên lập trình viên tự gỡ được ràng buộc.
  • **A. SAML với PowerUserAccess nhưng từ chối mọi dịch vụ trừ Service Catalog — quá hạn chế, vi phạm yêu cầu không ảnh hưởng năng suất và không giới hạn dịch vụ khác.

Ghi nhớ

⚠ Bốn cách giới hạn theo Region — bảng phải thuộc: | Cách | Phạm vi | Ai gỡ được | |---|---|---| | SCP với aws:RequestedRegion | cả tài khoản | chỉ tài khoản quản lý | | IAM policy Deny | một danh tính | quản trị viên tài khoản | | Permissions boundary | một danh tính | quản trị viên tài khoản | | Tắt Region trong Account settings | cả tài khoản | root |

Từ khoá nhận diện:

"use Active Directory" → SAML hoặc IAM Identity Center "least privilege without hurting productivity" → PowerUserAccess + Deny hẹp "restrict to one Region" → aws:RequestedRegion "standardized approved products" → Service Catalog

⚠ Ba chính sách quản lý hay gặp: | Chính sách | Phạm vi | |---|---| | AdministratorAccess | tất cả | | PowerUserAccess | tất cả trừ IAM, Organizations | | ReadOnlyAccess | đọc mọi thứ, kể cả nội dung object |

Ba lưu ý về SAML: | Lưu ý | Chi tiết | |---|---| | AssumeRoleWithSAML trả credential tạm | | | Thuộc tính SAML ánh xạ sang vai trò | | | Thời hạn phiên tối đa 12 giờ | |

⚠ Ánh xạ nhóm AD sang vai trò AWS:

<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
  <AttributeValue>arn:aws:iam::111122223333:role/LapTrinhVien,
    arn:aws:iam::111122223333:saml-provider/AD</AttributeValue>
</Attribute>

Một người thuộc nhiều nhóm AD
    → thấy nhiều vai trò để chọn
      lúc đăng nhập

Ba lưu ý về Region toàn cầu: | Dịch vụ | Endpoint nằm ở | |---|---| | IAM | us-east-1 | | CloudFront | us-east-1 | | Route 53 | us-east-1 | | Organizations | us-east-1 |

⚠ Nhớ loại trừ chúng khi chặn theo Region:

"NotAction": ["iam:*", "cloudfront:*",
              "route53:*", "organizations:*",
              "support:*", "sts:*"]

Không loại trừ: chặn luôn cả việc
  đăng nhập hoặc tạo vai trò
        ↓
    Câu này chỉ chặn `rds:*` nên
      không gặp vấn đề đó

Ba lưu ý về kiểm soát chi phí: | Công cụ | Việc | |---|---| | AWS Budgets | cảnh báo khi vượt ngưỡng | | Cost Anomaly Detection | phát hiện tăng bất thường | | SCP theo Region | chặn từ gốc |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi lời gọi bị từ chối | | | Access Advisor xem dịch vụ nào thật sự dùng | | | RoleSessionName truy về người dùng AD | |

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Permission set gán cho nhiều tài khoản | | | Có cổng đăng nhập sẵn | | | Hỗ trợ AD, Okta, Azure AD, kho danh tính nội bộ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tạo RDS ở us-west-2 — phải bị từ chối | | | Thử tạo EC2 ở us-west-2 — phải chạy được | | | Thử sửa chính sách của chính mình — phải bị từ chối | |

Và một lời khuyên: hãy thêm cùng ràng buộc đó vào SCP chứ đừng chỉ để trong chính sách IAM. Một chính sách gắn vào vai trò vẫn nằm trong tầm với của bất kỳ ai có quyền IAM trong tài khoản đó — còn SCP thì chỉ tài khoản quản lý gỡ được, và đó mới là ranh giới thật sự.

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

A company has built a serverless electronic document management system for users to upload their documents. The system also has a web application that connects to an Amazon API Gateway with Regional endpoints which in turn invokes AWS Lambda functions. The Lambda functions write the metadata of the documents to the Amazon Aurora Serverless database before uploading the actual documents to the Amazon S3 bucket. While the serverless architecture has been tested in the US East (N. Virginia) Region, the solution should be scalable for other AWS Regions too.

As an AWS Certified Solutions Architect Professional, which options would you recommend to make the architecture scalable while offering low latency service to customers of any AWS region? (Select two)

  1. A

    Enable S3 Transfer Acceleration on the S3 bucket and configure the web application to use the Transfer Acceleration endpoints
  2. B

    Change the API Gateway Regional endpoints to edge-optimized endpoints
  3. C

    Configure AWS Global Accelerator to front the CloudFront distribution for providing low latency access to customers of all AWS regions
  4. D

    Change the API Gateway Regional endpoints to private API endpoints
  5. E

    Configure CloudFront to use signed URLs for providing low latency access to customers of all AWS regions
Xem giải thích

Đáp án

**A và B — Bật S3 Transfer Acceleration trên bucket và cho ứng dụng web dùng endpoint tăng tốc; đồng thời đổi endpoint của API Gateway từ Regional sang edge-optimized.

Vì sao đúng

Đề có hai đường dữ liệu khác nhau, và mỗi đáp án tăng tốc một đường: | Đường | Nội dung | Cách tăng tốc | |---|---|---| | Client → API Gateway | lời gọi API, ghi siêu dữ liệu | edge-optimized endpoint | | Client → S3 | tải tài liệu lên | Transfer Acceleration |

⚠ Điểm mấu chốt: cả hai đều dùng mạng biên của CloudFront:

Client ở châu Á gọi endpoint
  Regional ở us-east-1
        ↓
    Toàn bộ đường đi qua Internet
      công cộng
    → độ trễ cao và không ổn định
        ↓
    Edge-optimized: vào mạng AWS ở
      điểm biên gần nhất
    → phần còn lại đi trên xương
      sống AWS

Đổi sang edge-optimized:

aws apigateway update-rest-api --rest-api-id abc123 \
  --patch-operations \
    op=replace,path=/endpointConfiguration/types/REGIONAL,\
value=EDGE

⚠ Ba loại endpoint của API Gateway — bảng phải thuộc: | Loại | Đường đi | Hợp với | |---|---|---| | Edge-optimized | qua điểm biên CloudFront | client phân tán toàn cầu | | Regional | thẳng tới Region | client cùng Region | | Private | chỉ trong VPC | nội bộ, không ra Internet |

⚠ Đây là lý do phương án D sai:

Private endpoint chỉ truy cập
  được từ trong VPC
        ↓
    Ứng dụng web công khai sẽ
      không gọi được nữa
        ↓
    Đó là làm hỏng, không phải
      tăng tốc

Bật Transfer Acceleration:

aws s3api put-bucket-accelerate-configuration \
  --bucket tai-lieu-nguoi-dung \
  --accelerate-configuration Status=Enabled

Dùng endpoint tăng tốc:

import boto3
from botocore.config import Config

s3 = boto3.client('s3', config=Config(
    s3={'use_accelerate_endpoint': True}))
s3.upload_file('tai-lieu.pdf', 'tai-lieu-nguoi-dung', 'ho-so/tai-lieu.pdf')

⚠ Endpoint tăng tốc có tên miền riêng, phải khai đúng:

Bình thường:
  tai-lieu-nguoi-dung.s3.amazonaws.com
        ↓
    Tăng tốc:
  tai-lieu-nguoi-dung.s3-accelerate.amazonaws.com
        ↓
    Bật cờ trên bucket mà client
      vẫn gọi endpoint cũ
    → không có tác dụng gì

⚠ Và Transfer Acceleration chỉ tính tiền khi THẬT SỰ nhanh hơn:

AWS so tốc độ qua điểm biên với
  tốc độ đi thẳng
        ↓
    Không nhanh hơn → KHÔNG tính
      phí tăng tốc
        ↓
    Đây là chính sách hiếm gặp
      và rất đáng biết

Đo thử trước khi bật:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
  en/accelerate-speed-comparsion.html

⚠ Và vì sao phương án C sai:

C nói đặt Global Accelerator
  TRƯỚC một CloudFront distribution
        ↓
    Cả hai đều là dịch vụ biên
    → xếp chồng không cộng thêm
      lợi ích gì
        ↓
    Và đề không có CloudFront
      distribution nào cả

⚠ Hai dịch vụ này giải quyết bài toán khác nhau: | Tiêu chí | CloudFront | Global Accelerator | |---|---|---| | Cache | CÓ | KHÔNG | | Giao thức | HTTP/HTTPS | TCP, UDP | | IP tĩnh | không | CÓ |

⚠ Và vì sao phương án E sai:

Signed URL kiểm soát AI được
  truy cập nội dung
        ↓
    Đó là tính năng BẢO MẬT
    → không liên quan gì tới
      độ trễ

⚠ Và Aurora Serverless vẫn là nút thắt liên Region — đề không hỏi tới:

CSDL nằm ở us-east-1
    → client châu Á ghi siêu dữ liệu
      vẫn phải đi tới đó
        ↓
    Muốn giải quyết thật sự:
      Aurora Global Database
    → nhưng chỉ có bản đọc ở Region
      phụ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lời gọi API vào mạng AWS sớm hơn | | | Tải tệp lớn nhanh hơn đáng kể từ xa | | | Không đổi kiến trúc, chỉ đổi cấu hình | |

⚠ Và Transfer Acceleration hiệu quả nhất với tệp lớn từ xa:

Tệp nhỏ, client gần Region
    → gần như không cải thiện
        ↓
    Tệp trăm MB, client cách nửa
      vòng trái đất
    → cải thiện có thể tới 50-500%

⚠ Và multipart upload nên bật kèm:

from boto3.s3.transfer import TransferConfig
cau_hinh = TransferConfig(
    multipart_threshold=8*1024*1024,
    max_concurrency=10,
    multipart_chunksize=8*1024*1024)
s3.upload_file('lon.pdf', KHO, 'lon.pdf', Config=cau_hinh)

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

  • **C. Đặt Global Accelerator trước một CloudFront distribution để giảm độ trễ — đây là phương án gần nhất và Global Accelerator thật sự giảm độ trễ toàn cầu, nhưng xếp chồng hai dịch vụ biên không cộng thêm lợi ích, và kiến trúc trong đề không có CloudFront distribution.
  • **E. Dùng signed URL của CloudFront để phục vụ khách hàng mọi Region — signed URL là cơ chế kiểm soát truy cập, không liên quan tới độ trễ.
  • **D. Đổi endpoint của API Gateway sang private endpoint — private endpoint chỉ gọi được từ trong VPC, sẽ làm ứng dụng web công khai ngừng hoạt động.

Ghi nhớ

⚠ Bốn cách giảm độ trễ toàn cầu — bảng phải thuộc: | Cách | Dùng cho | |---|---| | CloudFront | nội dung web tĩnh và động | | Global Accelerator | TCP/UDP, IP tĩnh, chuyển Region | | S3 Transfer Acceleration | tải lên/xuống S3 | | API Gateway edge-optimized | lời gọi API |

Từ khoá nhận diện:

"global users, API latency" → edge-optimized endpoint "upload large files from far away" → S3 Transfer Acceleration "static IP + failover across Regions" → Global Accelerator "cache content near users" → CloudFront

Ba lưu ý về endpoint API Gateway: | Lưu ý | Chi tiết | |---|---| | Edge-optimized dùng CloudFront do AWS quản | | | Chứng chỉ cho edge-optimized phải ở us-east-1 | | | Regional cho phép tự đặt CloudFront trước | |

⚠ Tự đặt CloudFront trước Regional endpoint linh hoạt hơn:

Edge-optimized: không kiểm soát
  được cấu hình CloudFront
        ↓
    Regional + CloudFront tự dựng:
      chọn được cache policy, WAF,
      hàm ở biên
        ↓
    AWS hiện khuyến nghị cách này

Ba lưu ý về Transfer Acceleration: | Lưu ý | Chi tiết | |---|---| | Tên bucket không được chứa dấu chấm | | | Không hỗ trợ PUT Object - Copy | | | Chỉ tính phí khi thật sự nhanh hơn | |

⚠ Dấu chấm trong tên bucket là ràng buộc bất ngờ:

`cong-ty.tai-lieu` — có dấu chấm
        ↓
    Không bật được Transfer
      Acceleration
    → vì chứng chỉ wildcard không
      khớp tên miền nhiều cấp

Ba lưu ý về tải tệp lớn: | Lưu ý | Chi tiết | |---|---| | Multipart bắt buộc trên 5 GB | | | Tải song song nhiều phần | | | Dọn phần dở dang bằng luật vòng đời | |

Ba lưu ý về Aurora Serverless: | Lưu ý | Chi tiết | |---|---| | v2 co giãn từ 0,5 tới 128 ACU | | | Data API cho phép gọi qua HTTP | | | Global Database cho bản đọc ở Region khác | |

⚠ Data API rất hợp với Lambda:

rds = boto3.client('rds-data')
rds.execute_statement(
    resourceArn=ARN_CUM, secretArn=ARN_SECRET,
    database='tai_lieu',
    sql='INSERT INTO sieu_du_lieu (ma, ten) VALUES (:ma, :ten)',
    parameters=[{'name':'ma','value':{'stringValue':'TL-1'}},
                {'name':'ten','value':{'stringValue':'Hop dong'}}])

Không cần gộp kết nối, không cần
  đặt Lambda trong VPC

Ba lưu ý về kiến trúc nhiều Region: | Thành phần | Cách mở rộng | |---|---| | S3 | Cross-Region Replication | | DynamoDB | Global Tables | | Aurora | Global Database | | Lambda + API GW | triển khai ở mỗi Region + Route 53 latency |

Ba lưu ý về đo lường: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều khu vực | CloudWatch Synthetics canary | | So trước và sau khi bật | chạy thử nghiệm A/B | | Theo dõi Latency của API Gateway | tách IntegrationLatency |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy công cụ so tốc độ của S3TA | | | Đo thời gian tải một tệp lớn từ châu Á | | | So Latency của API trước và sau | |

Và một lời khuyên: hãy chạy công cụ so tốc độ của S3 Transfer Acceleration trước khi bật nó cho sản xuất. Với client ở gần Region, tăng tốc gần như không có tác dụng — và bật nó chỉ thêm một endpoint nữa phải cấu hình đúng trong mọi client.

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

An IT company wants to move all its clients belonging to the regulated and security-sensitive industries such as financial services and healthcare to the AWS Cloud as it wants to leverage the out-of-box security-specific capabilities offered by AWS. The Security team at the company is developing a framework to validate the adoption of AWS best practices and industry-recognized compliance standards. The AWS Management Console is the preferred method for the in-house teams wanting to provision resources. You have been hired as an AWS Certified Solutions Architect Professional to spearhead this strategic initiative.

Which of the following strategies would you adopt to address these business requirements for continuously assessing, auditing and monitoring the configurations of AWS resources? (Select two)

  1. A

    Enable trails and set up CloudTrail events to review and monitor management activities of all AWS accounts by logging these activities into CloudWatch Logs using a KMS key. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services
  2. B

    Leverage CloudWatch Logs agent to collect all the AWS SDK logs. Search the log data using a pre-defined set of filter patterns that match mutating API calls. Use CloudWatch alarms to send notifications via SNS when unintended changes are performed. Archive log data by using a batch export to Amazon S3 and analyze via Athena
  3. C

    Leverage CloudTrail integration with SNS to automatically notify unauthorized API activities. Ensure that CloudTrail is enabled for all accounts as well as all available AWS services. Use Lambda functions to automatically revert non-authorized changes in AWS resources
  4. D

    Leverage EventBridge events near-real-time capabilities to monitor system events patterns to trigger Lambda functions to automatically revert non-authorized changes in AWS resources. Send notifications via SNS topics to improve the incidence response time
  5. E

    Leverage Config rules to audit changes to AWS resources and monitor the compliance of the configuration by running the evaluations for the rule at a frequency that you choose. Develop AWS Config custom rules to establish a test-driven development approach by triggering the evaluation when any resource that matches the rule's scope changes in configuration
Xem giải thích

Đáp án

**A và E — Bật CloudTrail ở mọi tài khoản và mọi dịch vụ, ghi log vào CloudWatch Logs có mã hoá bằng khoá KMS để rà soát hoạt động quản trị; và dùng AWS Config rule để kiểm toán thay đổi tài nguyên, kèm custom rule kích hoạt đánh giá mỗi khi tài nguyên trong phạm vi thay đổi cấu hình.

Vì sao đúng

Đề dùng đúng cụm từ mô tả AWS Config, và cần cả hai dịch vụ:

"Liên tục đánh giá, kiểm toán và
  giám sát CẤU HÌNH của tài nguyên"
        ↓
    Đó là định nghĩa của AWS Config
        ↓
    Nhưng cấu hình chỉ là một nửa
    → còn cần biết AI đã làm gì
    → đó là CloudTrail

⚠ Hai dịch vụ trả lời hai câu hỏi khác nhau: | Dịch vụ | Câu hỏi | |---|---| | CloudTrail | AI đã gọi API nào, lúc nào, từ đâu | | AWS Config | tài nguyên này ĐANG cấu hình thế nào, có đúng chuẩn không |

Security group mở cổng 22 ra
  Internet
        ↓
    Config: "quy tắc này
      NON_COMPLIANT"
        ↓
    CloudTrail: "lúc 14:32 ngày
      31/8, vai trò X sửa nó"

Bật organization trail:

aws cloudtrail create-trail --name trail-toan-to-chuc \
  --s3-bucket-name kiem-toan-tap-trung \
  --is-organization-trail --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:ap-southeast-1:111122223333:key/abc \
  --cloud-watch-logs-log-group-arn <arn-log-group> \
  --cloud-watch-logs-role-arn <arn-role>

⚠ Bốn cờ trong lệnh trên đều quan trọng: | Cờ | Vì sao cần | |---|---| | is-organization-trail | một trail cho mọi tài khoản, kể cả tài khoản mới | | is-multi-region-trail | bắt cả hoạt động ở Region không dùng | | enable-log-file-validation | ký số, phát hiện log bị sửa | | kms-key-id | mã hoá log bằng khoá của mình |

⚠ Multi-Region là chi tiết an ninh, không chỉ là sự tiện lợi:

Kẻ tấn công thường hoạt động ở
  Region công ty không dùng
        ↓
    Trail chỉ ở một Region
    → không thấy gì
        ↓
    Multi-region trail bắt hết

⚠ Và log file validation là thứ hay bị quên:

aws cloudtrail validate-logs \
  --trail-arn <arn-trail> \
  --start-time 2026-08-01T00:00:00Z

CloudTrail ký số mỗi tệp log và
  sinh tệp digest
        ↓
    Ai sửa hoặc xoá log
    → kiểm chứng thất bại
        ↓
    Không có nó: log là bằng chứng
      không đáng tin

⚠ Và ghi vào CloudWatch Logs cho phép cảnh báo gần thời gian thực:

Chỉ ghi vào S3
    → phải chờ tệp được giao
      (tới 15 phút)
    → rồi mới phân tích được
        ↓
    Thêm CloudWatch Logs: đặt
      metric filter và alarm
    → cảnh báo trong vài phút

aws logs put-metric-filter --log-group-name trail-logs \
  --filter-name goi-api-that-bai \
  --filter-pattern '{ ($.errorCode = "*UnauthorizedOperation")
                   || ($.errorCode = "AccessDenied*") }' \
  --metric-transformations \
    metricName=LoiUyQuyen,metricNamespace=KiemToan,metricValue=1

Custom Config rule kích hoạt theo thay đổi:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "kiem-tra-rieng",
  "Source": {"Owner": "CUSTOM_LAMBDA",
             "SourceIdentifier": "<arn-lambda>",
             "SourceDetails": [{
               "EventSource": "aws.config",
               "MessageType": "ConfigurationItemChangeNotification"}]},
  "Scope": {"ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"]}}'

⚠ ConfigurationItemChangeNotification là cách đánh giá tức thì: | Kiểu kích hoạt | Khi nào chạy | |---|---| | ConfigurationItemChangeNotification | ngay khi tài nguyên đổi | | ScheduledNotification | theo chu kỳ đã đặt |

Đề nói "chạy đánh giá ở tần suất
  bạn chọn" và "kích hoạt khi tài
  nguyên trong phạm vi thay đổi"
        ↓
    Cả hai kiểu đều được nhắc
    → phương án E mô tả đúng

⚠ Và vì sao phương án B sai:

B nói dùng CloudWatch Logs agent
  thu thập "log của AWS SDK"
        ↓
    SDK không ghi log ở đâu cả
      theo mặc định
        ↓
    Và lời gọi API từ console hay
      CLI của người khác không
      qua SDK của bạn
    → bỏ sót phần lớn hoạt động

⚠ Và vì sao phương án C và D chỉ là một phần:

C: CloudTrail + SNS + Lambda tự
  hoàn tác thay đổi
        ↓
    D: EventBridge + Lambda tự
      hoàn tác
        ↓
    Cả hai là ỨNG PHÓ tự động
    → đề hỏi "đánh giá, kiểm toán,
      giám sát CẤU HÌNH"
    → tự hoàn tác thay đổi không
      phải là kiểm toán

Và tự hoàn tác mọi thay đổi
  "không được uỷ quyền"
    → rất dễ hoàn tác nhầm việc
      hợp lệ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Biết cả trạng thái lẫn lịch sử thay đổi | | | Áp cho toàn tổ chức, tài khoản mới tự vào | | | Log có chữ ký, dùng làm bằng chứng được | |

⚠ Và với ngành tài chính, y tế thì conformance pack tiết kiệm rất nhiều công:

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name hipaa \
  --template-s3-uri \
    s3://mau/Operational-Best-Practices-for-HIPAA-Security.yaml

AWS có sẵn gói cho HIPAA, PCI-DSS,
  NIST, CIS, SOC 2
        ↓
    Hàng chục quy tắc triển khai
      bằng một lệnh

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

  • **D. Dùng EventBridge giám sát mẫu sự kiện gần thời gian thực, gọi Lambda tự hoàn tác thay đổi không được phép, gửi thông báo qua SNS — đây là phương án gần nhất và thật sự phản ứng rất nhanh, nhưng đó là cơ chế ứng phó chứ không phải đánh giá và kiểm toán cấu hình; và tự hoàn tác rất dễ hoàn tác nhầm thay đổi hợp lệ.
  • **C. Dùng tích hợp CloudTrail với SNS để báo hoạt động API trái phép và Lambda tự hoàn tác — CloudTrail không tự phân loại đâu là "trái phép"; phải có Config hoặc GuardDuty đánh giá.
  • **B. Dùng CloudWatch Logs agent thu thập log của AWS SDK và lọc theo mẫu — SDK không ghi log mặc định, và cách này bỏ sót mọi hoạt động không đi qua SDK của bạn.

Ghi nhớ

⚠ Bốn dịch vụ giám sát và kiểm toán — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | CloudTrail | ai làm gì (nhật ký API) | | AWS Config | tài nguyên cấu hình thế nào | | GuardDuty | có hành vi độc hại không | | Security Hub | tổng hợp và chấm điểm tuân thủ |

Từ khoá nhận diện:

"continuously assess configuration" → AWS Config "who made this change" → CloudTrail "detect compromised credentials, crypto mining" → GuardDuty "compliance score against CIS/PCI" → Security Hub

Ba lưu ý về CloudTrail: | Lưu ý | Chi tiết | |---|---| | Management event ghi mặc định 90 ngày trong Event history | | | Data event phải bật riêng và tính phí | | | Organization trail gom mọi tài khoản | |

⚠ Event history khác với trail:

Event history: 90 ngày gần nhất,
  miễn phí, chỉ management event
        ↓
    Trail: lưu vào S3 vô thời hạn,
      cấu hình được
        ↓
    Kiểm toán dài hạn phải có trail

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | SCP cấm cloudtrail:StopLogging | | | Bucket ở tài khoản riêng, chỉ ghi | | | S3 Object Lock chống xoá | |

⚠ Bucket log nên nằm ở tài khoản khác:

Kẻ tấn công chiếm tài khoản sản xuất
        ↓
    Không xoá được log vì log nằm
      ở tài khoản kiểm toán
        ↓
    Đây là mẫu "log archive account"
      của Control Tower

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Bật ở từng Region, từng tài khoản | | | Aggregator gom kết quả về một chỗ | | | Giới hạn loại tài nguyên để kiểm soát chi phí | |

Ba loại quy tắc Config: | Loại | Đặc điểm | |---|---| | Managed | AWS viết sẵn, hàng trăm luật | | Custom Lambda | viết bằng mã | | Custom Policy (Guard) | DSL khai báo, không cần Lambda |

Ba lưu ý về mã hoá log: | Lưu ý | Chi tiết | |---|---| | Khoá KMS phải cho phép CloudTrail dùng | | | Người đọc log cần quyền kms:Decrypt | | | Xoay khoá tự động hằng năm | |

Ba lưu ý về phân tích: | Công cụ | Việc | |---|---| | Athena | truy vấn SQL trên log trong S3 | | CloudWatch Logs Insights | truy vấn gần thời gian thực | | Security Lake | chuẩn hoá log theo OCSF |

⚠ Truy vấn CloudTrail bằng Athena:

SELECT eventtime, useridentity.arn, eventname, sourceipaddress
FROM cloudtrail_logs
WHERE eventname = 'ConsoleLogin'
  AND responseelements LIKE '%Failure%'
  AND eventtime > '2026-08-01';

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sửa một security group, xem Config có bắt | | | Chạy validate-logs kiểm tra toàn vẹn | | | Kiểm aggregator có đủ mọi tài khoản | |

Và một lời khuyên: hãy đặt bucket log ở một tài khoản riêng mà không ai có quyền xoá. CloudTrail bật đầy đủ vẫn vô dụng nếu kẻ chiếm được tài khoản cũng chiếm luôn nơi lưu bằng chứng — và đó chính là việc đầu tiên mà một kẻ tấn công có kinh nghiệm sẽ làm.