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

Tìm thấy 1221 câu.

Câu 451 Chọn nhiều đáp án Design Solutions for Organizational Complexity

A company has various business units, each holding its AWS account. With a growing number of different AWS accounts, the company has decided to use AWS Organizations to centralize permissions and access controls. As a solutions architect, you have been asked to define Service Control Policies (SCPs) for the company.

Which of the following represent true statements about SCPs? (Select two)

  1. A

    If both a permissions boundary and an SCP are present, then the boundary and the identity-based policy must all allow the action. Permissions boundary overwrites the SCP in such a scenario
  2. B

    The specified actions from an attached SCP affect all IAM identities including the root user of the member account
  3. C

    If a user has an IAM policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user cannot perform that action
  4. D

    An Amazon S3 bucket is owned by account A in an organization. The bucket policy (a resource-based policy) grants access to users from account B outside the organization. Account A has an SCP attached. By the flow of hierarchy, account B will now have SCP attached to it
  5. E

    The SCP denies access to all Amazon EC2 instances. The service-linked roles of the member accounts will not be able to access the EC2 instances with these existing roles
Xem giải thích

Đáp án

**B và C — Các hành động trong SCP đã gắn ảnh hưởng tới mọi danh tính IAM, kể cả root của tài khoản thành viên; và nếu người dùng có chính sách IAM cho phép một hành động mà SCP không cho phép hoặc từ chối tường minh, họ vẫn không làm được hành động đó.

Vì sao đúng

Hai mệnh đề này diễn đạt đúng bản chất của SCP: nó là trần quyền, không phải chính sách cấp quyền.

⚠ Điểm mấu chốt: quyền thực tế là GIAO của SCP và chính sách IAM:

        SCP                 IAM policy
   (trần quyền)            (cấp quyền)
        ↓                       ↓
        └────────GIAO───────────┘
                  ↓
            Quyền thực tế

SCP không cho phép → không làm được
        ↓
    IAM không cho phép → không làm
      được
        ↓
    Phải CẢ HAI cùng cho phép

⚠ Và SCP áp cả cho root của tài khoản thành viên — điều rất đáng nhớ:

Root user thường vượt qua mọi chính
  sách IAM
        ↓
    Nhưng KHÔNG vượt qua được SCP
        ↓
    Đây là cách duy nhất giới hạn
      root của tài khoản con
    → và là lý do chính để dùng
      Organizations

⚠ Nhưng SCP KHÔNG áp cho root của tài khoản QUẢN LÝ:

Tài khoản quản lý miễn nhiễm SCP
        ↓
    Kể cả SCP gắn ở gốc tổ chức
        ↓
    Thiết kế như vậy để tránh tự khoá
      mình ra ngoài
    → nhưng cũng nghĩa là không nên
      chạy tải sản xuất ở đó

⚠ Và vì sao mệnh đề E sai — service-linked role là ngoại lệ:

E nói SCP chặn EC2 thì service-linked
  role cũng không truy cập được
        ↓
    SAI: SCP KHÔNG áp cho
      service-linked role
        ↓
    Vì các dịch vụ AWS cần vai trò đó
      để hoạt động
    → chặn được là làm hỏng chính
      dịch vụ

Bốn thứ SCP không áp:

1. Tài khoản quản lý của tổ chức
2. Service-linked role
3. Tài nguyên không thuộc tổ chức
4. Một số hành động toàn cục có tính
     nền tảng

⚠ Và vì sao mệnh đề A sai — permissions boundary không "ghi đè" SCP:

A nói "permissions boundary ghi đè
  SCP"
        ↓
    Không có khái niệm ghi đè ở đây
        ↓
    SCP, boundary và chính sách IAM
      đều phải CÙNG cho phép
    → đó là giao ba chiều, không phải
      thứ tự ưu tiên

Thứ tự đánh giá đầy đủ:

1. Deny tường minh ở BẤT KỲ đâu → TỪ CHỐI
        ↓
2. SCP không cho phép → TỪ CHỐI
        ↓
3. Resource-based policy cho phép → CHO PHÉP
     (bỏ qua các bước sau ở một số ca)
        ↓
4. Permissions boundary không cho → TỪ CHỐI
        ↓
5. Session policy không cho → TỪ CHỐI
        ↓
6. Identity-based policy cho phép → CHO PHÉP
        ↓
7. Mặc định → TỪ CHỐI

⚠ Và vì sao mệnh đề D sai — SCP không "lan" sang tài khoản ngoài:

D nói bucket policy cấp quyền cho
  tài khoản B ngoài tổ chức
        ↓
    Rồi kết luận "B sẽ bị SCP của A
      áp vào"
        ↓
    SAI: SCP áp cho DANH TÍNH trong
      tổ chức, không áp cho tài
      nguyên hay cho tài khoản ngoài

⚠ Nhưng SCP CÓ ảnh hưởng gián tiếp tới truy cập liên tài khoản:

Người dùng trong tài khoản A gọi
  bucket ở tài khoản B
        ↓
    SCP của tổ chức A vẫn áp cho
      người dùng đó
        ↓
    Chặn `s3:*` trong SCP → không gọi
      được, dù bucket policy bên kia
      cho phép

Tạo và gắn SCP:

aws organizations create-policy \
  --name chan-vung-ngoai-danh-sach \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp.json \
  --description "Chi cho phep hai Region"

aws organizations attach-policy \
  --policy-id p-abc123 \
  --target-id ou-abc-11111111

⚠ Và phải bật "all features mode" mới dùng được SCP:

aws organizations describe-organization \
  --query 'Organization.FeatureSet'

`CONSOLIDATED_BILLING` → KHÔNG dùng
  được SCP
        ↓
    `ALL` → dùng được
        ↓
    Chuyển từ billing sang all features
      cần mọi tài khoản thành viên chấp
      thuận

⚠ Và SCP mặc định FullAWSAccess gắn sẵn ở mọi nơi:

Gốc tổ chức và mọi OU có sẵn
  `FullAWSAccess`
        ↓
    Cho phép `*` trên `*`
        ↓
    Gỡ nó ra → mọi thứ bị chặn ngay
    → gần như luôn giữ nguyên và thêm
      SCP deny bên cạnh

SCP deny-list điển hình:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanRoiToChuc",
   "Effect": "Deny",
   "Action": ["organizations:LeaveOrganization"],
   "Resource": "*"},
  {"Sid": "ChanTatCloudTrail",
   "Effect": "Deny",
   "Action": ["cloudtrail:StopLogging",
              "cloudtrail:DeleteTrail"],
   "Resource": "*"}]}

⚠ Và SCP kế thừa theo cây, luôn thu hẹp dần:

Gốc: cho phép tất cả
   └─ OU-SanXuat: chỉ 2 Region
        └─ Tài khoản A: thêm deny S3
             ↓
    Trần cuối cùng = GIAO của cả ba
        ↓
    Không tầng nào MỞ RỘNG được trần
      của tầng trên

Xem trần thực tế:

aws organizations describe-effective-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --target-id 111122223333

⚠ Và có công cụ ước lượng tác động trước khi gắn:

aws organizations list-policies-for-target \
  --target-id ou-abc-11111111 \
  --filter SERVICE_CONTROL_POLICY

Không có "dry run" thật cho SCP
        ↓
    Cách an toàn: gắn vào OU thử
      nghiệm trước
        ↓
    Rồi mới lan ra OU sản xuất

Ba lợi ích của SCP: | Lợi ích | Chi tiết | |---|---| | Giới hạn được cả root của tài khoản con | | | Không sửa được từ bên trong tài khoản | | | Áp một lần cho cả OU | |

⚠ Và giới hạn kích thước là ràng buộc thực tế:

Mỗi SCP tối đa 5.120 ký tự
        ↓
    Tối đa 5 SCP gắn vào một mục tiêu
        ↓
    Danh sách dài phải chia nhiều
      chính sách
    → hoặc dùng `NotAction` cho gọn

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

  • **E. SCP chặn EC2 thì service-linked role cũng không truy cập được — đây là phương án gần nhất và nghe rất hợp lý theo logic "SCP áp cho mọi danh tính", nhưng service-linked role là ngoại lệ được ghi rõ trong tài liệu: SCP không áp cho chúng, vì chặn được sẽ làm hỏng chính các dịch vụ AWS.
  • **A. Permissions boundary ghi đè SCP — không có khái niệm ghi đè; SCP, boundary và chính sách IAM phải cùng cho phép.
  • **D. Tài khoản B ngoài tổ chức bị SCP áp vào qua bucket policy — SCP áp cho danh tính trong tổ chức, không lan sang tài khoản ngoài.

Ghi nhớ

⚠ Bốn thứ SCP KHÔNG áp — bảng phải thuộc: | Thứ | Vì sao | |---|---| | Tài khoản quản lý | tránh tự khoá mình | | Service-linked role | dịch vụ AWS cần chúng | | Tài nguyên ngoài tổ chức | ngoài phạm vi | | Chính sách dựa trên tài nguyên | SCP áp cho danh tính |

Từ khoá nhận diện:

"restrict the root user of member accounts" → SCP "SCP grants permission" → SAI, SCP chỉ đặt trần "consolidated billing mode" → KHÔNG dùng được SCP "maximum permissions for an IAM entity" → permissions boundary

Ba lưu ý về trần quyền: | Lưu ý | Chi tiết | |---|---| | Quyền thật = giao của mọi tầng | | | Không tầng nào mở rộng được trần trên | | | Deny tường minh thắng tất cả | |

Ba lưu ý về chế độ tổ chức: | Chế độ | Dùng được SCP | |---|---| | Consolidated billing | không | | All features | có | | Chuyển đổi cần mọi thành viên chấp thuận | |

Ba lưu ý về FullAWSAccess: | Lưu ý | Chi tiết | |---|---| | Gắn sẵn ở gốc và mọi OU | | | Gỡ ra là chặn hết | | | Nên giữ và thêm deny bên cạnh | |

Ba lưu ý về giới hạn: | Giới hạn | Giá trị | |---|---| | Kích thước mỗi SCP | 5.120 ký tự | | SCP mỗi mục tiêu | 5 | | Độ sâu OU | 5 tầng dưới gốc |

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | Thử ở OU nhỏ trước | | | Ưu tiên deny-list hơn allow-list | | | Kiểm bằng describe-effective-policy | |

Ba lưu ý về permissions boundary: | Lưu ý | Chi tiết | |---|---| | Áp cho một IAM user hoặc role | | | Không cấp quyền, chỉ đặt trần | | | Dùng để uỷ quyền tạo vai trò an toàn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử hành động bị chặn từ tài khoản con | | | Thử bằng chính root của tài khoản con | | | Đọc describe-effective-policy | |

Và một lời khuyên: hãy nhớ rằng SCP không bao giờ cấp quyền cho ai. Rất nhiều sự cố bắt đầu từ việc ai đó viết một SCP Allow rồi ngạc nhiên vì người dùng vẫn bị từ chối — trần quyền chỉ nói cái gì được phép tồn tại, còn quyền thật vẫn phải đến từ chính sách IAM.

Câu 452 Accelerate Workload Migration and Modernization

An e-commerce company is migrating from its on-premises data center to AWS Cloud in a phased manner. As part of the test deployments, the company chose Amazon FSx for Windows File Server with Single-AZ 2 deployment as one of the solutions. After viability testing, it became apparent that the company will need a highly available and fault-tolerant shared Windows file data system to cater to its data storage requirements.

As a solutions architect, what changes will you suggest in the current configuration to make it highly available while keeping the downtime low?

  1. A

    Set up a new Amazon FSx file system with a Multi-AZ deployment type. Leverage AWS DataSync to transfer data from the old file system to the new one. Point the application to the new Multi-AZ file system
  2. B

    Replicate the existing architecture and create another Single-AZ 2 deployment Amazon FSx for Windows File Server. Configure AWS DataSync to continuously back up data from the old file system to the new one. Use the second system as a failover option
  3. C

    Shut down the existing FSx file system and change the configuration to Multi-AZ through AWS CLI. Restart the file system which will now be a Multi-AZ deployment
  4. D

    Set up a new Amazon FSx file system with a deployment type of Multi-AZ. Leverage AWS Database Migration Service (DMS) to transfer data to the new Amazon FSx file system. Point users to the new location
Xem giải thích

Đáp án

**A — Dựng một hệ thống tệp Amazon FSx mới với kiểu triển khai Multi-AZ; dùng AWS DataSync chuyển dữ liệu từ hệ thống cũ sang; rồi trỏ ứng dụng sang hệ thống Multi-AZ mới.

Vì sao đúng

Điểm quyết định của câu này là một sự thật về FSx:

KHÔNG đổi được kiểu triển khai của
  một hệ thống tệp FSx đã tạo
        ↓
    Single-AZ không chuyển thành
      Multi-AZ được
        ↓
    Phải TẠO MỚI và di chuyển dữ liệu

⚠ Điểm mấu chốt: vì sao phương án C bất khả thi:

C nói tắt hệ thống, đổi cấu hình
  sang Multi-AZ bằng CLI, rồi khởi
  động lại
        ↓
    FSx không có lệnh nào làm được
      việc đó
        ↓
    Và FSx cũng không có khái niệm
      "tắt rồi bật lại" hệ thống tệp
    → hai điều sai trong một phương án

Cái gì đổi được sau khi tạo: | Thuộc tính | Đổi được | |---|---| | Dung lượng lưu trữ | tăng được | | Throughput capacity | được | | Cửa sổ bảo trì | được | | Thời gian giữ backup | được | | Kiểu triển khai (Single/Multi-AZ) | KHÔNG | | Loại lưu trữ (SSD/HDD) | KHÔNG | | Subnet, VPC | KHÔNG |

⚠ Và DataSync là công cụ đúng để chuyển dữ liệu giữa hai FSx:

aws datasync create-location-fsx-windows \
  --fsx-filesystem-arn <arn-fsx-cu> \
  --security-group-arns <arn-sg> \
  --user quantri --password '...' --domain CONGTY

aws datasync create-task \
  --source-location-arn <arn-nguon> \
  --destination-location-arn <arn-dich> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,PreserveDeletedFiles=REMOVE

⚠ Và DataSync giữ được siêu dữ liệu Windows — điều rất quan trọng:

Chuyển bằng robocopy hay xcopy thường
        ↓
    Dễ mất ACL, quyền NTFS, timestamp
        ↓
    DataSync giữ:
      - ACL của NTFS
      - quyền sở hữu
      - dấu thời gian
    → người dùng không thấy khác gì

⚠ Và vì sao phương án D sai — DMS không chuyển tệp:

D dùng AWS Database Migration Service
        ↓
    DMS di trú CƠ SỞ DỮ LIỆU
        ↓
    Nguồn và đích là engine CSDL
        ↓
    Nó không đọc được hệ thống tệp
      SMB
    → sai công cụ hoàn toàn

⚠ Và vì sao phương án B không đạt yêu cầu:

B tạo thêm một Single-AZ nữa làm dự
  phòng
        ↓
    Chuyển đổi khi hỏng phải làm TAY
        ↓
    Đề đòi "sẵn sàng cao và chịu lỗi"
        ↓
    Multi-AZ chuyển đổi TỰ ĐỘNG
    → hai Single-AZ không phải là
      Multi-AZ

Multi-AZ hoạt động thế nào:

Hai máy chủ tệp ở hai AZ
        ↓
    Máy chính hoạt động, máy phụ chờ
        ↓
    Dữ liệu sao chép đồng bộ
        ↓
    Máy chính hỏng → DNS name tự trỏ
      sang máy phụ
    → thường dưới 30 giây

⚠ Và tên DNS không đổi khi chuyển đổi — đó là điểm mấu chốt:

Client mount bằng tên DNS của hệ
  thống tệp
        ↓
    Chuyển đổi xong, tên vẫn thế
        ↓
    Client tự kết nối lại
    → không phải sửa gì ở phía client

⚠ Và thời gian ngừng khi di trú phụ thuộc cách cắt chuyển:

1. DataSync chạy lần đầu (dữ liệu lớn)
        ↓
2. Chạy lại vài lần để bắt kịp thay
     đổi
        ↓
3. Ngừng ghi vào hệ thống cũ
        ↓
4. Chạy DataSync lần cuối
        ↓
5. Trỏ client sang hệ thống mới
    → chỉ ngừng ở bước 3-5

⚠ Và nên dùng DNS alias để client không phải sửa gì:

aws fsx associate-file-system-aliases \
  --file-system-id fs-moi \
  --aliases kho-chung.congty.local

Client mount bằng alias
        ↓
    Chuyển alias sang hệ thống mới
        ↓
    Không phải sửa đường dẫn ở hàng
      trăm máy trạm

⚠ Và alias cần thêm Service Principal Name trong Active Directory:

setspn -S HOST/kho-chung.congty.local <ten-may-fsx>
setspn -S HOST/kho-chung <ten-may-fsx>

Thiếu SPN → xác thực Kerberos thất
  bại
        ↓
    Client rơi về NTLM hoặc bị từ chối
    → đây là bước hay quên nhất

⚠ Và Multi-AZ đắt hơn Single-AZ khoảng gấp đôi:

Lưu trữ nhân đôi (hai AZ)
        ↓
    Throughput capacity tính hai lần
        ↓
    Cộng phí truyền dữ liệu giữa AZ
    → đổi lấy chuyển đổi tự động

Bảng ba kiểu triển khai: | Kiểu | Đặc điểm | |---|---| | Single-AZ 1 | thế hệ cũ, rẻ nhất | | Single-AZ 2 | SSD, hiệu năng cao hơn, hỗ trợ shard | | Multi-AZ | chuyển đổi tự động, đắt gấp đôi |

⚠ Và Single-AZ vẫn có sao lưu tự động:

Backup hằng ngày, lưu ở nhiều AZ
        ↓
    Khôi phục được khi AZ hỏng
        ↓
    Nhưng phải khôi phục THỦ CÔNG
        ↓
    RTO tính bằng giờ, không phải giây

Ba lợi ích của Multi-AZ: | Lợi ích | Chi tiết | |---|---| | Chuyển đổi tự động dưới 30 giây | | | Bảo trì không gây gián đoạn | | | Tên DNS không đổi | |

⚠ Và bảo trì là lý do bị bỏ qua nhưng rất thực tế:

Single-AZ trong cửa sổ bảo trì
        ↓
    Hệ thống tệp KHÔNG dùng được vài
      phút
        ↓
    Multi-AZ: chuyển sang máy phụ,
      vá máy chính, chuyển lại
    → người dùng không nhận ra

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

  • **B. Tạo thêm một Single-AZ 2 nữa và dùng DataSync sao lưu liên tục làm dự phòng — đây là phương án gần nhất và thật sự có hai bản dữ liệu, nhưng chuyển đổi phải làm thủ công và DataSync là sao chép định kỳ chứ không đồng bộ, nên vẫn mất dữ liệu và không đạt "chịu lỗi".
  • **C. Tắt hệ thống và đổi cấu hình sang Multi-AZ bằng CLI — không có thao tác nào như vậy; kiểu triển khai không đổi được sau khi tạo.
  • **D. Dùng AWS DMS chuyển dữ liệu — DMS di trú cơ sở dữ liệu, không chuyển được tệp trên SMB.

Ghi nhớ

⚠ Bốn thuộc tính FSx không đổi được — bảng phải thuộc: | Thuộc tính | Muốn đổi phải | |---|---| | Kiểu triển khai | tạo mới + di trú | | Loại lưu trữ SSD/HDD | tạo mới + di trú | | VPC, subnet | tạo mới + di trú | | Active Directory đã gắn | tạo mới + di trú |

Từ khoá nhận diện:

"change Single-AZ to Multi-AZ" → tạo mới, không sửa được "copy files between file systems" → DataSync "migrate a database" → DMS "test Multi-AZ failover" → đổi throughput capacity

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Giữ ACL, quyền sở hữu, timestamp | | | Có xác minh dữ liệu sau khi chép | | | Chạy theo lịch được | |

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Sao chép đồng bộ giữa hai AZ | | | Chuyển đổi thường dưới 30 giây | | | Đắt khoảng gấp đôi Single-AZ | |

Ba lưu ý về DNS alias: | Lưu ý | Chi tiết | |---|---| | Tối đa 50 alias mỗi hệ thống tệp | | | Phải thêm SPN trong Active Directory | | | Cho phép chuyển hệ thống mà client không đổi gì | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudWatch cho dung lượng và hiệu năng | | | File access auditing qua CloudWatch Logs hoặc Firehose | | | Cảnh báo khi dung lượng còn ít | |

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Backup hằng ngày, lưu nhiều AZ | | | Giữ tối đa 90 ngày | | | AWS Backup quản tập trung được | |

Ba lưu ý về Active Directory: | Lưu ý | Chi tiết | |---|---| | Dùng AWS Managed AD hoặc AD tự quản | | | Đổi AD sau khi tạo không được | | | Cần đủ cổng mở giữa FSx và domain controller | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So ACL trước và sau khi chép | | | Thử chuyển đổi bằng cách đổi throughput | | | Đo thời gian client kết nối lại | |

Và một lời khuyên: hãy thử chuyển đổi Multi-AZ ít nhất một lần trước khi đưa vào sản xuất — cách chính thức là thay đổi throughput capacity, việc này kích hoạt chuyển đổi thật. Biết được ứng dụng của mình mất bao lâu để kết nối lại là thứ chỉ đo được, không suy luận được.

Câu 453 Continuous Improvement for Existing Solutions

A weather monitoring agency stores and manages the global weather data for the last 50 years. The data has a velocity of 1GB per minute. You would like to store the data with only the most relevant attributes to build a predictive model for weather patterns.

Which of the following solutions would you use to build the most cost-effective solution with the LEAST amount of infrastructure maintenance?

  1. A

    Capture the data in Kinesis Data Firehose and use an intermediary Lambda function to filter and transform the incoming stream before the output is dumped on S3
  2. B

    Capture the data in a Spark Streaming Cluster on EMR use Spark Streaming transformations before writing to S3
  3. C

    Capture the data in Kinesis Data Streams and use an intermediary Lambda function to filter and transform the incoming stream before the output is dumped on S3
  4. D

    Capture the data in Kinesis Data Analytics and use SQL queries to filter and transform the data before writing to S3
Xem giải thích

Đáp án

**A — Nhận dữ liệu bằng Kinesis Data Firehose và dùng một hàm Lambda trung gian để lọc và biến đổi luồng dữ liệu trước khi ghi ra S3.

Vì sao đúng

Đề đòi rẻ nhất và ít bảo trì hạ tầng nhất. Firehose là dịch vụ duy nhất trong bốn phương án không có gì để vận hành.

⚠ Điểm mấu chốt: Firehose không có shard, không có cụm, không có gì để chỉnh: | | Firehose | Data Streams | EMR | |---|---|---|---| | Co giãn | tự động | quản shard bằng tay hoặc on-demand | quản node | | Người tiêu thụ | không cần viết | phải viết | phải viết job Spark | | Ghi ra S3 | sẵn có | phải tự viết | phải tự viết | | Trả tiền | theo lượng dữ liệu | theo shard-giờ | theo instance-giờ |

⚠ Và Firehose gọi Lambda ngay trong đường ống:

Dữ liệu vào Firehose
        ↓
    Firehose gom thành lô
        ↓
    Gọi Lambda với cả lô
        ↓
    Lambda trả về bản đã lọc/biến đổi
        ↓
    Firehose ghi ra S3
    → không cần viết vòng lặp đọc nào

Cấu hình biến đổi:

aws firehose create-delivery-stream \
  --delivery-stream-name du-lieu-thoi-tiet \
  --extended-s3-destination-configuration '{
    "BucketARN": "arn:aws:s3:::kho-thoi-tiet",
    "RoleARN": "<arn-role>",
    "Prefix": "nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/ngay=!{timestamp:dd}/",
    "ErrorOutputPrefix": "loi/",
    "BufferingHints": {"SizeInMBs": 128, "IntervalInSeconds": 300},
    "CompressionFormat": "GZIP",
    "ProcessingConfiguration": {
      "Enabled": true,
      "Processors": [{
        "Type": "Lambda",
        "Parameters": [{
          "ParameterName": "LambdaArn",
          "ParameterValue": "<arn-lambda>"}]}]}}'

Hàm Lambda lọc thuộc tính:

import base64, json

CAN_GIU = {'nhiet_do', 'ap_suat', 'do_am', 'thoi_gian', 'toa_do'}

def handler(su_kien, ngu_canh):
    ket_qua = []
    for ban_ghi in su_kien['records']:
        goc = json.loads(base64.b64decode(ban_ghi['data']))
        loc = {k: v for k, v in goc.items() if k in CAN_GIU}
        ket_qua.append({
            'recordId': ban_ghi['recordId'],
            'result': 'Ok',
            'data': base64.b64encode(
                (json.dumps(loc) + '\n').encode()).decode()})
    return {'records': ket_qua}

⚠ Và ba giá trị result có ý nghĩa khác nhau — phải nắm: | Giá trị | Nghĩa | |---|---| | Ok | giữ bản ghi đã biến đổi | | Dropped | bỏ có chủ ý, không phải lỗi | | ProcessingFailed | lỗi — ghi vào tiền tố lỗi |

Lọc bỏ bản ghi không cần
        ↓
    Phải trả `Dropped`, KHÔNG phải
      `ProcessingFailed`
        ↓
    Trả nhầm → bản ghi rác chất đống
      trong thư mục lỗi
    → và cảnh báo lỗi kêu suốt

⚠ Và phải trả lại ĐÚNG mọi recordId nhận được:

Thiếu một recordId trong phản hồi
        ↓
    Firehose coi cả lô là thất bại
        ↓
    Toàn bộ lô vào tiền tố lỗi
    → kể cả những bản ghi tốt

⚠ Và có giới hạn kích thước phản hồi:

Phản hồi của Lambda tối đa 6 MB
        ↓
    Nếu biến đổi làm dữ liệu PHÌNH RA
        ↓
    Có thể vượt giới hạn
        ↓
    Ở đây ta LỌC BỚT nên an toàn
    → nhưng phải nhớ khi làm việc
      ngược lại

⚠ Và vì sao phương án C tốn công hơn:

C dùng Kinesis Data Streams
        ↓
    Phải tự quản số shard
        ↓
    1 GB/phút ≈ 17 MB/giây
        ↓
    Mỗi shard nhận 1 MB/giây
    → cần ít nhất 17 shard, và phải
      chia lại khi tải đổi

⚠ Và Data Streams còn phải tự viết người tiêu thụ ghi ra S3:

Lambda đọc từ stream
        ↓
    Tự gom lô, tự nén, tự đặt tên tệp
        ↓
    Tự xử lý thử lại khi ghi S3 hỏng
    → đó chính là những gì Firehose
      làm sẵn

⚠ Và vì sao phương án B nặng nhất:

B dùng Spark Streaming trên EMR
        ↓
    Phải chọn loại instance, số node
        ↓
    Phải vá hệ điều hành, nâng cấp
      phiên bản Spark
        ↓
    Phải theo dõi job có chết không
    → nhiều bảo trì nhất trong bốn
      phương án

⚠ Và vì sao phương án D không phải lựa chọn tốt nhất ở đây:

D dùng Kinesis Data Analytics với SQL
        ↓
    Hợp với PHÂN TÍCH theo cửa sổ
      thời gian
        ↓
    Ví dụ: trung bình 5 phút, phát
      hiện bất thường
        ↓
    Việc ở đây chỉ là LỌC CỘT
    → dùng SQL streaming cho việc này
      là quá mức

⚠ Và buffer của Firehose là chỗ đánh đổi:

Buffer lớn → tệp lớn, ít yêu cầu S3,
  rẻ hơn
        ↓
    Buffer nhỏ → dữ liệu tới S3 nhanh
      hơn
        ↓
    Tối thiểu 60 giây (hoặc 0 khi bật
      chế độ không buffer)
    → "gần thời gian thực", không
      phải "thời gian thực"

⚠ Và tệp nhỏ là kẻ thù của phân tích:

Buffer 1 MB
        ↓
    Hàng nghìn tệp nhỏ mỗi ngày
        ↓
    Athena quét chậm, tốn nhiều yêu
      cầu
    → nên để buffer 128 MB cho tải
      lớn

⚠ Và nên phân vùng động theo thời gian:

Prefix có `!{timestamp:yyyy}/...`
        ↓
    Dữ liệu tự chia thư mục theo ngày
        ↓
    Athena chỉ quét phân vùng cần
    → giảm chi phí truy vấn rất nhiều

⚠ Và Firehose chuyển được sang Parquet ngay trong đường ống:

{"DataFormatConversionConfiguration": {
  "Enabled": true,
  "SchemaConfiguration": {
    "DatabaseName": "kho_thoi_tiet",
    "TableName": "do_dac",
    "RoleARN": "<arn-role>"},
  "OutputFormatConfiguration": {
    "Serializer": {"ParquetSerDe": {}}}}}

Đọc lược đồ từ Glue Data Catalog
        ↓
    Ghi thẳng ra Parquet
        ↓
    Không cần job ETL riêng
    → giảm dữ liệu quét thêm 90%

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

⚠ Hai dịch vụ trong câu này đã đổi tên: | Tên trong đề | Tên hiện nay | |---|---| | Kinesis Data Firehose | Amazon Data Firehose (2024) | | Kinesis Data Analytics | Amazon Managed Service for Apache Flink (2023) |

Chức năng không đổi
        ↓
    Nhưng tài liệu và console dùng tên
      mới
    → đọc đề cũ thì phải tự dịch sang

Ba lợi ích của Firehose ở đây: | Lợi ích | Chi tiết | |---|---| | Không có gì để vận hành | | | Trả tiền theo lượng dữ liệu thật | | | Ghi ra S3 và nén sẵn | |

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

  • **C. Kinesis Data Streams + Lambda trung gian — đây là phương án gần nhất và kiến trúc gần như giống hệt, nhưng Data Streams đòi tự quản số shard (17 shard cho 1 GB/phút) và phải tự viết phần ghi ra S3 mà Firehose làm sẵn.
  • **B. Spark Streaming trên EMR — nhiều bảo trì nhất: chọn instance, vá hệ điều hành, theo dõi job.
  • **D. Kinesis Data Analytics với truy vấn SQL — hợp cho phân tích theo cửa sổ thời gian, quá mức cho việc chỉ lọc bớt cột.

Ghi nhớ

⚠ Bốn dịch vụ luồng dữ liệu — bảng phải thuộc: | Dịch vụ | Chọn khi | |---|---| | Data Firehose | nạp vào S3/Redshift/OpenSearch, không cần vận hành | | Data Streams | cần nhiều người tiêu thụ, cần lưu lại 365 ngày | | Managed Flink | phân tích theo cửa sổ thời gian | | MSK | cần Kafka API |

Từ khoá nhận diện:

"least infrastructure maintenance" → Firehose "multiple consumers, replay data" → Data Streams "real-time (dưới 1 giây)" → Data Streams, không phải Firehose "windowed aggregation" → Managed Flink

Ba lưu ý về biến đổi bằng Lambda: | Lưu ý | Chi tiết | |---|---| | Phải trả đủ mọi recordId | | | Dropped khác ProcessingFailed | | | Phản hồi tối đa 6 MB | |

Ba lưu ý về buffer: | Lưu ý | Chi tiết | |---|---| | Tối thiểu 60 giây với đích S3 | | | Buffer lớn cho tệp lớn, rẻ hơn | | | Có chế độ không buffer cho độ trễ thấp | |

Ba lưu ý về ghi ra S3: | Lưu ý | Chi tiết | |---|---| | Phân vùng động theo timestamp | | | Nén GZIP hoặc Snappy | | | Chuyển sang Parquet ngay trong đường ống | |

Ba lưu ý về xử lý lỗi: | Lưu ý | Chi tiết | |---|---| | ErrorOutputPrefix giữ bản ghi hỏng | | | Theo dõi metric DeliveryToS3.Success | | | Cảnh báo khi tỷ lệ lỗi tăng | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Firehose tính theo GB nạp vào | | | Biến đổi bằng Lambda tính riêng | | | Chuyển sang Parquet tính riêng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem tệp ra có đúng cột đã lọc không | | | Kiểm tiền tố lỗi có rỗng không | | | Đo kích thước tệp trung bình | |

Và một lời khuyên: hãy trả về Dropped chứ đừng trả ProcessingFailed cho bản ghi bị lọc bỏ có chủ ý. Đây là lỗi rất hay gặp khi viết hàm biến đổi lần đầu, và hậu quả là thư mục lỗi đầy dữ liệu hoàn toàn bình thường — khiến cảnh báo lỗi thật bị chôn vùi giữa nhiễu.

Câu 454 Design Solutions for Organizational Complexity

A retail company has two web applications and wants to run them in separate, isolated VPCs. The company is looking at using Elastic Load Balancing to distribute requests between application instances. The security and compliance team at the company has imposed the following restrictions:

  1. Inbound HTTP requests to the application must be routed through a centralized VPC

  2. Application VPCs must not be exposed to any other inbound traffic

  3. Application VPCs cannot be allowed to initiate any outbound connections

  4. Internet gateways must not be attached to the application VPCs

Which of the following solutions would you recommend to address these requirements?

  1. A

    Configure the applications behind private Network Load Balancers (NLBs) in separate VPCs. Set up each NLB as an AWS PrivateLink endpoint service with associated VPC endpoints in the centralized VPC. Set up a public Application Load Balancer (ALB) in the centralized VPC and point the target groups to the private IP addresses of each endpoint. Set up host-based routing to route application traffic to the corresponding target group through the ALB
  2. B

    Configure the applications behind private Network Load Balancers (NLBs) in separate VPCs. Set up VPC Peering between application VPCs and the centralized VPC. Set up a public Application Load Balancer (ALB) in the centralized VPC and point the target groups to the private DNS names of the NLBs. Set up host-based routing to route application traffic to the corresponding target group through the ALB
  3. C

    Configure the applications behind private Application Load Balancers (ALBs) in separate VPCs. Set up a public Network Load Balancer (NLB) in the centralized VPC and point the target groups to the ALBs. Set up host-based routing to route application traffic to the corresponding target group through the NLB
  4. D

    Configure the applications behind private Application Load Balancers (ALBs) in separate VPCs. Set up a public Network Load Balancer (NLB) in the centralized VPC and point the target groups to the private IP addresses of the ALBs. Set up host-based routing to route application traffic to the corresponding target group through the NLB
Xem giải thích

Đáp án

**A — Đặt ứng dụng sau các Network Load Balancer riêng tư trong từng VPC; dựng mỗi NLB thành một AWS PrivateLink endpoint service với VPC endpoint tương ứng ở VPC trung tâm; đặt một Application Load Balancer công khai ở VPC trung tâm và trỏ target group tới địa chỉ IP riêng tư của từng endpoint; định tuyến theo host.

Vì sao đúng

Đề đưa ra bốn ràng buộc, và chỉ PrivateLink thoả cả bốn: | Ràng buộc | PrivateLink | |---|---| | Vào qua VPC trung tâm | ALB công khai duy nhất ở đó | | VPC ứng dụng không nhận lưu lượng vào khác | chỉ endpoint service tiếp nhận | | VPC ứng dụng không được chủ động ra ngoài | PrivateLink một chiều | | Không gắn Internet Gateway | không cần |

⚠ Điểm mấu chốt: PrivateLink là kết nối MỘT CHIỀU:

Consumer (VPC trung tâm) gọi Provider
  (VPC ứng dụng)
        ↓
    Provider KHÔNG khởi tạo kết nối
      ngược được
        ↓
    Đây là khác biệt cốt lõi với
      peering
    → và đúng ràng buộc thứ ba của đề

⚠ Và đây là lý do phương án B thất bại:

B dùng VPC peering
        ↓
    Peering là hai chiều
        ↓
    VPC ứng dụng khởi tạo được kết nối
      sang VPC trung tâm
        ↓
    Vi phạm "không được chủ động ra
      ngoài"

⚠ Và peering còn phơi bày cả mạng:

Peering nối TOÀN BỘ dải CIDR
        ↓
    Không chỉ một dịch vụ
        ↓
    Vi phạm "không nhận lưu lượng vào
      nào khác"
    → PrivateLink chỉ lộ đúng một
      endpoint

⚠ Và vì sao ALB trong VPC ứng dụng không dùng được với PrivateLink:

Endpoint service chỉ nhận NLB (hoặc
  GWLB) làm mặt trước
        ↓
    ALB KHÔNG làm endpoint service
      được
        ↓
    → đó là lý do phương án C và D sai
      ngay từ cấu trúc

Muốn dùng ALB ở VPC ứng dụng
        ↓
    Đặt NLB trước ALB
        ↓
    NLB làm endpoint service, target
      là ALB
    → cách này hợp lệ nhưng thêm một
      tầng

Dựng endpoint service:

aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns <arn-nlb-ung-dung> \
  --acceptance-required \
  --supported-ip-address-types ipv4

Dựng endpoint ở VPC trung tâm:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-trung-tam \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.vpce.ap-southeast-1.vpce-svc-abc \
  --subnet-ids subnet-tt-1 subnet-tt-2 \
  --security-group-ids sg-endpoint

⚠ Và endpoint tạo ra ENI có IP riêng tư trong VPC trung tâm:

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-abc \
  --query 'VpcEndpoints[0].NetworkInterfaceIds'

aws ec2 describe-network-interfaces \
  --network-interface-ids eni-abc \
  --query 'NetworkInterfaces[0].PrivateIpAddress'

Chính IP này là target của ALB
        ↓
    Target type phải là `ip`
    → không phải `instance`

Đăng ký IP endpoint vào target group:

aws elbv2 create-target-group \
  --name tg-ung-dung-1 --protocol HTTP --port 80 \
  --vpc-id vpc-trung-tam --target-type ip

aws elbv2 register-targets \
  --target-group-arn <arn-tg> \
  --targets Id=10.0.1.15 Id=10.0.2.20

⚠ Và đây là điểm yếu phải biết: IP của endpoint có thể đổi:

ENI của endpoint giữ IP ổn định
  trong vòng đời của nó
        ↓
    Nhưng tạo lại endpoint → IP mới
        ↓
    Target group không tự cập nhật
    → cần tự động hoá bằng EventBridge
      + Lambda nếu tái tạo thường xuyên

Định tuyến theo host:

aws elbv2 create-rule --listener-arn <arn-listener> \
  --priority 10 \
  --conditions Field=host-header,Values='ung-dung-1.congty.vn' \
  --actions Type=forward,TargetGroupArn=<arn-tg-1>

aws elbv2 create-rule --listener-arn <arn-listener> \
  --priority 20 \
  --conditions Field=host-header,Values='ung-dung-2.congty.vn' \
  --actions Type=forward,TargetGroupArn=<arn-tg-2>

Luồng hoàn chỉnh:

Người dùng Internet
    ↓
ALB công khai (VPC trung tâm)
    ↓ định tuyến theo host
Target group → IP của VPC endpoint
    ↓ PrivateLink
Endpoint service
    ↓
NLB riêng tư (VPC ứng dụng)
    ↓
EC2 trong subnet riêng tư

⚠ Và CIDR chồng lấn cũng không sao:

Hai VPC ứng dụng có thể cùng
  10.0.0.0/16
        ↓
    PrivateLink không cần định tuyến
      giữa hai mạng
        ↓
    Lưu lượng đi qua ENI trong VPC
      trung tâm
    → đây là ưu điểm lớn so với
      peering

⚠ Và IP nguồn mà backend thấy là IP của NLB:

Không bật preserve client IP
        ↓
    EC2 thấy IP của node NLB
        ↓
    Muốn biết IP người dùng thật
    → đọc header `X-Forwarded-For`
      do ALB thêm vào

⚠ Và phải chấp nhận yêu cầu kết nối khi bật acceptance-required:

aws ec2 accept-vpc-endpoint-connections \
  --service-id vpce-svc-abc \
  --vpc-endpoint-ids vpce-abc

Không chấp nhận → endpoint kẹt ở
  trạng thái `pendingAcceptance`
        ↓
    Không có lỗi rõ ràng ở phía
      consumer
    → chỉ thấy kết nối không đi đâu
      cả

Ba lợi ích của PrivateLink: | Lợi ích | Chi tiết | |---|---| | Lộ đúng một dịch vụ, không lộ mạng | | | Một chiều, provider không gọi ngược được | | | CIDR chồng lấn vẫn dùng được | |

⚠ Và chi phí là điều cần biết trước:

Endpoint tính phí theo giờ mỗi AZ
        ↓
    Cộng phí theo GB xử lý
        ↓
    Nhiều dịch vụ × nhiều AZ → cộng
      dồn nhanh
    → nhưng đây là cái giá của việc
      thoả bốn ràng buộc bảo mật

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

  • **B. NLB riêng tư + VPC peering giữa các VPC ứng dụng và VPC trung tâm — đây là phương án gần nhất và kết nối được về mặt mạng, nhưng peering là hai chiều nên VPC ứng dụng khởi tạo được kết nối ra ngoài, vi phạm ràng buộc thứ ba; và nó phơi toàn bộ dải CIDR chứ không chỉ một dịch vụ. Ngoài ra ALB không trỏ target tới tên DNS của NLB được.
  • **C. ALB riêng tư trong VPC ứng dụng, NLB công khai ở VPC trung tâm trỏ tới các ALB — NLB không dùng ALB làm target theo cách này qua ranh giới VPC, và không có cơ chế kết nối nào giữa hai VPC.
  • **D. Giống C nhưng trỏ tới địa chỉ IP riêng tư của ALB — IP của ALB thay đổi liên tục, và vẫn thiếu đường kết nối giữa hai VPC.

Ghi nhớ

⚠ Bốn cách nối VPC — bảng phải thuộc: | Cách | Chiều | Phạm vi lộ ra | |---|---|---| | PrivateLink | một chiều | một dịch vụ | | Peering | hai chiều | toàn bộ CIDR | | Transit Gateway | hai chiều | toàn bộ CIDR | | VPN | hai chiều | theo route |

Từ khoá nhận diện:

"must not initiate outbound connections" → PrivateLink "expose only one service" → PrivateLink "overlapping CIDR" → PrivateLink "no internet gateway in app VPC" → PrivateLink hoặc NAT ở VPC khác

Ba lưu ý về endpoint service: | Lưu ý | Chi tiết | |---|---| | Chỉ NLB hoặc GWLB làm mặt trước | | | acceptance-required phải chấp nhận thủ công | | | Cho phép principal cụ thể được kết nối | |

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Tạo ENI có IP riêng tư trong VPC consumer | | | Tính phí theo giờ mỗi AZ + theo GB | | | Gắn security group để lọc thêm | |

Ba lưu ý về ALB target type: | Type | Dùng khi | |---|---| | instance | EC2 trong cùng VPC | | ip | IP bất kỳ trong VPC hoặc qua endpoint | | lambda | gọi thẳng hàm Lambda |

Ba lưu ý về định tuyến: | Lưu ý | Chi tiết | |---|---| | Định tuyến theo host cần chứng chỉ cho mọi tên | | | Ưu tiên luật theo số priority | | | Luật mặc định nên trả 404 hoặc 403 | |

Ba lưu ý về IP nguồn: | Lưu ý | Chi tiết | |---|---| | Backend thấy IP của NLB | | | X-Forwarded-For giữ IP thật | | | NLB bật preserve client IP thì khác | |

Ba lưu ý về vận hành: | Lưu ý | Chi tiết | |---|---| | IP endpoint đổi khi tạo lại | | | Theo dõi HealthyHostCount của target group | | | Bật Flow Log ở cả hai VPC | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử gọi từ VPC ứng dụng ra ngoài — phải hỏng | | | Kiểm không có Internet Gateway nào gắn | | | Gọi qua ALB công khai — phải bình thường | |

Và một lời khuyên: hãy nhớ rằng endpoint service chỉ nhận NLB làm mặt trước. Đây là ràng buộc loại bỏ được hai phương án trong câu này chỉ bằng một câu hỏi — và trong thực tế nó là thứ khiến nhiều thiết kế phải chèn thêm một NLB trước ALB đã có.

Câu 455 Accelerate Workload Migration and Modernization

A bioinformatics company leverages multiple open source tools to manage data analysis workflows running on its on-premises servers to process biological data which is generated and stored on a Network Attached Storage (NAS). The existing workflow receives around 100 GB of input biological data for each job run and individual jobs can take several hours to process the data. The CTO at the company wants to re-architect its proprietary analytics workflow on AWS to meet the workload demands and reduce the turnaround time from months to days. The company has provisioned a high-speed AWS Direct Connect connection. The final result needs to be stored in Amazon S3. The company is expecting approximately 20 job requests each day.

Which of the following options would you recommend for the given use case?

  1. A

    Leverage AWS Data Pipeline to transfer the biological data to Amazon S3. Use S3 events to trigger an Amazon EC2 Auto Scaling group to launch custom-AMI EC2 instances to process the biological data
  2. B

    Leverage AWS Storage Gateway file gateway to transfer the biological data to Amazon S3. Use S3 events to trigger an AWS Lambda function that starts an AWS Step Functions workflow for orchestrating an AWS Batch job that processes the biological data
  3. C

    Leverage AWS Data Pipeline to transfer the biological data to Amazon S3. Use S3 events to trigger an AWS Step Functions workflow for orchestrating an AWS Batch job that processes the biological data
  4. D

    Leverage AWS DataSync to transfer the biological data to Amazon S3. Use S3 events to trigger an AWS Lambda function that starts an AWS Step Functions workflow for orchestrating an AWS Batch job that processes the biological data
Xem giải thích

Đáp án

**D — Dùng AWS DataSync chuyển dữ liệu sinh học sang Amazon S3; dùng sự kiện S3 kích hoạt một hàm Lambda khởi động một luồng Step Functions để điều phối một job AWS Batch xử lý dữ liệu.

Vì sao đúng

Đề có bốn manh mối, và đáp án khớp cả bốn: | Manh mối | Thành phần | |---|---| | NAS tại chỗ + Direct Connect | DataSync | | Job chạy vài giờ, 100 GB đầu vào | AWS Batch | | Luồng công việc nhiều bước | Step Functions | | 20 job mỗi ngày, không đều | Batch tự co giãn |

⚠ Điểm mấu chốt: DataSync là công cụ chuyển tệp, Data Pipeline thì không:

DataSync: chuyên chuyển tệp giữa NFS,
  SMB, HDFS, S3, EFS, FSx
        ↓
    Data Pipeline: điều phối luồng dữ
      liệu giữa các kho AWS
        ↓
    Nó không nói được giao thức NFS
      tới NAS tại chỗ
    → sai công cụ ở phương án A và C

⚠ Và AWS Data Pipeline đã ngừng nhận khách hàng mới từ tháng 7/2024:

AWS khuyến nghị chuyển sang Step
  Functions, Glue hoặc MWAA
        ↓
    Khách cũ vẫn chạy tiếp
        ↓
    → phương án A và C dùng dịch vụ
      đang bị khai tử

⚠ Và DataSync nhanh hơn công cụ tự viết nhiều lần:

Agent chạy tại chỗ, đọc từ NAS
        ↓
    Truyền song song nhiều luồng
        ↓
    Nén và tối ưu giao thức trên
      đường truyền
    → AWS công bố nhanh gấp 10 lần
      công cụ chép tệp thông thường

Dựng DataSync:

aws datasync create-location-nfs \
  --server-hostname nas.noi-bo.local \
  --subdirectory /du-lieu-sinh-hoc \
  --on-prem-config AgentArns=<arn-agent>

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::du-lieu-sinh-hoc \
  --s3-config BucketAccessRoleArn=<arn-role>

aws datasync create-task \
  --source-location-arn <arn-nfs> \
  --destination-location-arn <arn-s3> \
  --options VerifyMode=ONLY_FILES_TRANSFERRED,TransferMode=CHANGED

⚠ Và TransferMode=CHANGED chỉ chuyển tệp mới hoặc đã đổi:

Chạy lại tác vụ
        ↓
    So sánh siêu dữ liệu
        ↓
    Bỏ qua tệp không đổi
    → tiết kiệm băng thông và thời
      gian rất nhiều

⚠ Và vì sao AWS Batch là lựa chọn đúng cho phần xử lý:

Job chạy VÀI GIỜ
        ↓
    Lambda tối đa 15 phút
        ↓
    → Lambda không xử lý được dữ liệu
        ↓
    Batch chạy container không giới
      hạn thời gian

⚠ Và Batch tự dựng và tự dẹp máy tính toán:

Không có job → 0 instance → 0 đồng
        ↓
    Có job → dựng đúng số máy cần
        ↓
    Job xong → dẹp
        ↓
    20 job/ngày không đều
    → không phải nuôi cụm chạy suốt

Định nghĩa môi trường tính toán:

aws batch create-compute-environment \
  --compute-environment-name moi-truong-sinh-hoc \
  --type MANAGED --state ENABLED \
  --compute-resources '{
    "type": "SPOT",
    "allocationStrategy": "SPOT_CAPACITY_OPTIMIZED",
    "minvCpus": 0, "maxvCpus": 512,
    "instanceTypes": ["c5", "m5", "r5"],
    "subnets": ["subnet-a", "subnet-b"],
    "securityGroupIds": ["sg-batch"],
    "bidPercentage": 60,
    "instanceRole": "<arn-instance-profile>"}'

⚠ Và minvCpus: 0 là chi tiết quan trọng:

Đặt `minvCpus` lớn hơn 0
        ↓
    Luôn có instance chạy chờ việc
        ↓
    Trả tiền cả lúc không có job
        ↓
    Đặt 0 → chỉ trả tiền khi làm việc
    → đổi lại phải chờ máy khởi động

⚠ Và Spot hợp với công việc này:

Job phân tích chạy lại được
        ↓
    Bị thu hồi → Batch tự thử lại
        ↓
    Rẻ hơn tới 90%
        ↓
    Nhưng phải bật retry và viết job
      chịu được ngắt

{"retryStrategy": {
  "attempts": 3,
  "evaluateOnExit": [{
    "onStatusReason": "Host EC2*",
    "action": "RETRY"}]}}

⚠ Và Step Functions lo phần điều phối:

Một job phân tích thường nhiều bước:
    - kiểm tra dữ liệu đầu vào
    - chạy phân tích
    - kiểm kết quả
    - ghi vào S3
    - báo cáo
        ↓
    Step Functions nối các bước
        ↓
    Có xử lý lỗi, thử lại, rẽ nhánh
    → không phải nhét hết vào một
      script

Định nghĩa luồng gọi Batch:

{"StartAt": "ChayPhanTich",
 "States": {
   "ChayPhanTich": {
     "Type": "Task",
     "Resource": "arn:aws:states:::batch:submitJob.sync",
     "Parameters": {
       "JobName": "phan-tich-sinh-hoc",
       "JobQueue": "hang-doi-chinh",
       "JobDefinition": "dinh-nghia-phan-tich",
       "Parameters": {"duongDan.$": "$.khoaS3"}},
     "Retry": [{"ErrorEquals": ["States.ALL"],
                "IntervalSeconds": 60, "MaxAttempts": 2}],
     "Catch": [{"ErrorEquals": ["States.ALL"],
                "Next": "BaoLoi"}],
     "Next": "GhiKetQua"}}}

⚠ Và .sync là hậu tố quan trọng:

`batch:submitJob` → gửi rồi đi tiếp
      ngay
        ↓
    `batch:submitJob.sync` → CHỜ job
      xong mới đi tiếp
        ↓
    Job chạy vài giờ
    → phải dùng `.sync`, nếu không
      bước sau chạy khi chưa có kết
      quả

⚠ Và vì sao cần Lambda ở giữa S3 và Step Functions:

S3 Event Notification gửi được tới:
    SNS, SQS, Lambda, EventBridge
        ↓
    KHÔNG gửi thẳng tới Step Functions
        ↓
    → cần Lambda làm cầu nối

Hoặc dùng EventBridge:
        ↓
    Bật EventBridge notification cho
      bucket
        ↓
    EventBridge gọi thẳng Step
      Functions
    → bỏ được Lambda

aws s3api put-bucket-notification-configuration \
  --bucket du-lieu-sinh-hoc \
  --notification-configuration '{"EventBridgeConfiguration": {}}'

⚠ Và vì sao phương án B chọn sai công cụ chuyển dữ liệu:

B dùng Storage Gateway file gateway
        ↓
    File gateway là để TRUY CẬP S3 như
      một chia sẻ tệp
        ↓
    Nó là lớp cache thường trực, không
      phải công cụ di trú theo lô
    → dùng được nhưng không tối ưu cho
      100 GB mỗi lần

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

A dùng Auto Scaling group với AMI
  tuỳ chỉnh
        ↓
    Phải tự viết logic lấy việc từ đâu
        ↓
    Tự viết logic co giãn theo số job
        ↓
    Tự xử lý job hỏng
    → đó chính là những gì Batch làm
      sẵn

Ba lợi ích của kiến trúc này: | Lợi ích | Chi tiết | |---|---| | Không có máy nào chạy khi rảnh | | | Job hỏng tự thử lại | | | Nhìn thấy được từng bước trong Step Functions | |

⚠ Và đi qua Direct Connect thì nên dùng VPC endpoint cho S3:

DataSync agent ghi vào S3
        ↓
    Qua public VIF → đi Internet công
      cộng của AWS
        ↓
    Qua private VIF + gateway endpoint
    → hoàn toàn riêng tư

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

  • **B. Storage Gateway file gateway + Lambda + Step Functions + Batch — đây là phương án gần nhất và phần xử lý hoàn toàn đúng, nhưng file gateway là lớp cache để truy cập S3 như chia sẻ tệp, không phải công cụ di trú theo lô 100 GB mỗi job; DataSync nhanh hơn nhiều và có xác minh dữ liệu.
  • **C. Data Pipeline + Step Functions + Batch — Data Pipeline không nói được NFS tới NAS tại chỗ, và đã ngừng nhận khách hàng mới từ 7/2024.
  • **A. Data Pipeline + Auto Scaling group với AMI tuỳ chỉnh — sai công cụ chuyển dữ liệu, và phải tự viết toàn bộ logic hàng đợi, co giãn, thử lại mà Batch đã có sẵn.

Ghi nhớ

⚠ Bốn công cụ chuyển dữ liệu — bảng phải thuộc: | Công cụ | Dùng khi | |---|---| | DataSync | chuyển tệp qua mạng, có xác minh | | Snowball | dữ liệu quá lớn cho mạng | | Storage Gateway | truy cập lai thường trực | | Transfer Family | khách hàng dùng SFTP/FTPS |

Từ khoá nhận diện:

"copy from on-premises NFS to S3" → DataSync "jobs take several hours" → Batch, không phải Lambda "orchestrate multi-step workflow" → Step Functions "S3 event to Step Functions" → qua Lambda hoặc EventBridge

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Cần agent tại chỗ cho nguồn NFS/SMB | | | TransferMode=CHANGED bỏ qua tệp không đổi | | | Chạy được theo lịch | |

Ba lưu ý về AWS Batch: | Lưu ý | Chi tiết | |---|---| | minvCpus: 0 để không trả tiền lúc rảnh | | | Spot rẻ hơn tới 90%, cần bật retry | | | Job definition khai CPU, bộ nhớ, container | |

Ba lưu ý về Step Functions: | Lưu ý | Chi tiết | |---|---| | .sync để chờ job xong | | | Retry và Catch trên từng state | | | Standard workflow tối đa một năm | |

Ba lưu ý về sự kiện S3: | Lưu ý | Chi tiết | |---|---| | Đích: SNS, SQS, Lambda, EventBridge | | | Không gửi thẳng tới Step Functions | | | Bật EventBridge để có nhiều đích hơn | |

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Private VIF tới VPC, public VIF tới dịch vụ công | | | Gateway endpoint cho S3 miễn phí | | | Nên có VPN dự phòng | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | DataSync tính theo GB chuyển | | | Batch chỉ tính EC2 khi chạy | | | Step Functions Standard tính theo bước | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So checksum sau khi DataSync chép | | | Xem đồ thị thực thi Step Functions | | | Kiểm không có instance nào chạy lúc rảnh | |

Và một lời khuyên: hãy dùng batch:submitJob.sync chứ đừng dùng batch:submitJob. Với job chạy vài giờ, phiên bản không đồng bộ sẽ khiến bước tiếp theo chạy ngay lập tức trên kết quả chưa tồn tại — và luồng vẫn báo thành công, nên lỗi này rất khó nhận ra cho tới khi ai đó đọc kết quả cuối.

Câu 456 Continuous Improvement for Existing Solutions

A financial services company has multiple AWS accounts hosting its portfolio of IT applications that serve the company's retail and enterprise customers. A CloudWatch Logs agent is installed on each of the EC2 instances running these IT applications. The company wants to aggregate all security events in a centralized AWS account dedicated to log storage. The centralized operations team at the company needs to perform near-real-time gathering and collating events across multiple AWS accounts.

As a Solutions Architect Professional, which of the following solutions would you suggest to meet these requirements?

  1. A

    Set up Kinesis Data Firehose in the logging account and then subscribe the delivery stream to CloudWatch Logs streams in each application AWS account via subscription filters. Persist the log data in an Amazon S3 bucket inside the logging AWS account
  2. B

    Set up CloudWatch Logs agents to publish data to a Kinesis Data Firehose stream in the centralized logging AWS account. Create a Lambda function to read messages from the stream and push messages to Kinesis Data Firehose and then store the data in S3
  3. C

    Set up CloudWatch Logs streams in each application AWS account to forward events to CloudWatch Logs in the centralized logging AWS account. In the centralized logging AWS account, subscribe a Kinesis Data Firehose stream to Amazon EventBridge events and further use the Firehose stream to store the log data in S3
  4. D

    Set up a new IAM role in each application AWS account with permissions to view CloudWatch Logs. Create a Lambda function to assume this new role and perform an hourly export of each AWS account's CloudWatch Logs data to an S3 bucket in the centralized logging AWS account
Xem giải thích

Đáp án

**A — Dựng Kinesis Data Firehose ở tài khoản logging, rồi đăng ký luồng đó vào CloudWatch Logs của từng tài khoản ứng dụng qua subscription filter; lưu dữ liệu log vào một bucket S3 trong tài khoản logging.

Vì sao đúng

Đề có hai yêu cầu quyết định: gần thời gian thực và gom từ nhiều tài khoản về một chỗ. Subscription filter liên tài khoản là cơ chế được thiết kế đúng cho việc đó.

⚠ Điểm mấu chốt: subscription filter đẩy log ngay khi có, không phải chờ:

CloudWatch Logs nhận sự kiện
        ↓
    Subscription filter khớp mẫu
        ↓
    Đẩy sang đích NGAY
        ↓
    Độ trễ tính bằng giây
    → đúng nghĩa "gần thời gian thực"

⚠ Và đây là lý do phương án D thất bại:

D xuất log theo giờ bằng Lambda
        ↓
    `CreateExportTask` là tác vụ theo



      lô
        ↓
    Chạy mỗi giờ → độ trễ tới 60 phút
        ↓
    Đề đòi "gần thời gian thực"
    → sai về bản chất

⚠ Và CreateExportTask còn có ràng buộc khắc nghiệt:

Chỉ chạy được MỘT tác vụ xuất tại
  một thời điểm mỗi tài khoản
        ↓
    Hàng chục tài khoản, mỗi giờ một
      lần
        ↓
    Xếp hàng, chậm dần
    → không mở rộng được

Dựng luồng nhận ở tài khoản logging:

aws firehose create-delivery-stream \
  --delivery-stream-name gom-log-bao-mat \
  --extended-s3-destination-configuration '{
    "BucketARN": "arn:aws:s3:::kho-log-trung-tam",
    "RoleARN": "<arn-role-firehose>",
    "Prefix": "tai-khoan=!{partitionKeyFromQuery:taiKhoan}/nam=!{timestamp:yyyy}/thang=!{timestamp:MM}/",
    "BufferingHints": {"SizeInMBs": 64, "IntervalInSeconds": 60},
    "CompressionFormat": "GZIP"}'

Vai trò cho phép tài khoản ứng dụng ghi vào Firehose:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "logs.amazonaws.com"},
   "Action": "sts:AssumeRole",
   "Condition": {
     "StringLike": {"aws:SourceArn": [
       "arn:aws:logs:ap-southeast-1:222233334444:*",
       "arn:aws:logs:ap-southeast-1:333344445555:*"]}}}]}

Đặt destination policy ở tài khoản logging:

aws logs put-destination \
  --destination-name dich-gom-log \
  --target-arn <arn-firehose> \
  --role-arn <arn-role>

aws logs put-destination-policy \
  --destination-name dich-gom-log \
  --access-policy '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"AWS": ["222233334444", "333344445555"]},
      "Action": "logs:PutSubscriptionFilter",
      "Resource": "arn:aws:logs:ap-southeast-1:111122223333:destination:dich-gom-log"}]}'

Tạo subscription filter ở từng tài khoản ứng dụng:

aws logs put-subscription-filter \
  --log-group-name /ung-dung/bao-mat \
  --filter-name gui-ve-trung-tam \
  --filter-pattern '' \
  --destination-arn arn:aws:logs:ap-southeast-1:111122223333:destination:dich-gom-log

⚠ Và --filter-pattern '' nghĩa là gửi tất cả:

Chuỗi rỗng → khớp mọi sự kiện
        ↓
    Muốn lọc thì đặt mẫu
        ↓
    Ví dụ: `?ERROR ?CRITICAL`
    → lọc ở nguồn rẻ hơn lọc ở đích

⚠ Và giới hạn hai subscription filter mỗi log group là ràng buộc thật:

Một log group tối đa 2 subscription
  filter
        ↓
    Đã dùng một cho OpenSearch
        ↓
    Chỉ còn một chỗ
    → phải tính trước khi thiết kế

⚠ Và có destination policy dùng tổ chức thay vì liệt kê tài khoản:

{"Effect": "Allow",
 "Principal": "*",
 "Action": "logs:PutSubscriptionFilter",
 "Resource": "<arn-destination>",
 "Condition": {"StringEquals": {
   "aws:PrincipalOrgID": "o-abc123"}}}

Thêm tài khoản mới vào tổ chức
        ↓
    Không phải sửa chính sách
    → quan trọng khi có hàng chục tài
      khoản

⚠ Và vì sao phương án B sai về mặt kỹ thuật:

B nói CloudWatch Logs agent ghi
  THẲNG vào Firehose ở tài khoản khác
        ↓
    Agent chỉ ghi vào CloudWatch Logs
        ↓
    Nó không có đích Firehose
    → luồng dữ liệu đó không tồn tại

⚠ Và phần sau của B còn thừa:

B nói Lambda đọc từ stream rồi đẩy
  vào Firehose
        ↓
    Nhưng đã ở Firehose rồi
        ↓
    Đẩy vào Firehose lần nữa để làm gì
    → mô tả tự mâu thuẫn

⚠ Và vì sao phương án C không đúng:

C nói CloudWatch Logs stream chuyển
  tiếp sang CloudWatch Logs tài khoản
  khác
        ↓
    Không có cơ chế "log group này
      chuyển tiếp sang log group kia"
      giữa hai tài khoản
        ↓
    Cách duy nhất là subscription
      filter, và đích của nó là
      Firehose/Kinesis/Lambda
    → không phải log group khác

⚠ Và phần EventBridge trong C cũng sai:

C nói Firehose đăng ký sự kiện
  EventBridge
        ↓
    Log của ứng dụng không đi qua
      EventBridge
        ↓
    EventBridge nhận sự kiện thay đổi
      trạng thái, không nhận dòng log

Bảng ba đích của subscription filter: | Đích | Dùng khi | |---|---| | Kinesis Data Firehose | lưu vào S3, không cần vận hành | | Kinesis Data Streams | cần nhiều người tiêu thụ | | Lambda | xử lý từng sự kiện ngay |

⚠ Và log của CloudWatch tới Firehose bị nén sẵn:

Dữ liệu tới Firehose là JSON nén
  GZIP, mã hoá base64
        ↓
    Ghi thẳng ra S3 → tệp không đọc
      được bằng Athena
        ↓
    Cần Lambda giải nén và tách từng
      dòng
    → đây là bước hay bị quên

import base64, gzip, json

def handler(su_kien, ngu_canh):
    ket_qua = []
    for ban_ghi in su_kien['records']:
        nen = base64.b64decode(ban_ghi['data'])
        du_lieu = json.loads(gzip.decompress(nen))
        if du_lieu['messageType'] == 'CONTROL_MESSAGE':
            ket_qua.append({'recordId': ban_ghi['recordId'],
                            'result': 'Dropped'})
            continue
        dong = ''.join(
            json.dumps({'thoiGian': s['timestamp'],
                        'noiDung': s['message'],
                        'nhom': du_lieu['logGroup'],
                        'taiKhoan': du_lieu['owner']}) + '\n'
            for s in du_lieu['logEvents'])
        ket_qua.append({'recordId': ban_ghi['recordId'],
                        'result': 'Ok',
                        'data': base64.b64encode(dong.encode()).decode()})
    return {'records': ket_qua}

⚠ Và CONTROL_MESSAGE phải bỏ đi:

CloudWatch Logs gửi thông điệp kiểm
  tra khi thiết lập
        ↓
    Nó không phải log thật
        ↓
    Giữ lại → rác trong dữ liệu phân
      tích

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Độ trễ tính bằng giây | | | Không phải viết người tiêu thụ | | | Thêm tài khoản chỉ là thêm một filter | |

⚠ Và có lựa chọn mới hơn: CloudWatch Logs cross-account:

Từ 2023, CloudWatch có
  cross-account observability
        ↓
    Xem log và metric của nhiều tài
      khoản trong một console
        ↓
    Nhưng đó là để XEM
    → vẫn cần Firehose nếu muốn lưu
      dài hạn vào S3

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

  • **D. IAM role liên tài khoản + Lambda xuất log mỗi giờ sang S3 — đây là phương án gần nhất và thật sự gom được log về một chỗ, nhưng độ trễ tới một giờ nên không phải "gần thời gian thực", và CreateExportTask chỉ chạy được một tác vụ mỗi lần cho mỗi tài khoản.
  • **B. CloudWatch Logs agent ghi thẳng vào Firehose ở tài khoản trung tâm — agent chỉ ghi vào CloudWatch Logs, không có đích Firehose; và phần Lambda đọc rồi đẩy lại vào Firehose là mô tả tự mâu thuẫn.
  • **C. Chuyển tiếp log group sang log group ở tài khoản khác — không có cơ chế nào như vậy; và log ứng dụng không đi qua EventBridge.

Ghi nhớ

⚠ Bốn bước gom log liên tài khoản — bảng phải thuộc: | Bước | Ở đâu | |---|---| | 1. Tạo Firehose + bucket | tài khoản logging | | 2. put-destination | tài khoản logging | | 3. put-destination-policy | tài khoản logging | | 4. put-subscription-filter | từng tài khoản ứng dụng |

Từ khoá nhận diện:

"near-real-time across accounts" → subscription filter → Firehose "hourly export" → CreateExportTask, KHÔNG phải thời gian thực "multiple consumers of the logs" → Kinesis Data Streams "view logs from many accounts" → cross-account observability

Ba lưu ý về subscription filter: | Lưu ý | Chi tiết | |---|---| | Tối đa 2 filter mỗi log group | | | Đích: Firehose, Data Streams, Lambda | | | Lọc ở nguồn bằng filter-pattern | |

Ba lưu ý về dữ liệu tới Firehose: | Lưu ý | Chi tiết | |---|---| | JSON nén GZIP, mã hoá base64 | | | Cần Lambda giải nén và tách dòng | | | Bỏ CONTROL_MESSAGE | |

Ba lưu ý về destination policy: | Lưu ý | Chi tiết | |---|---| | Liệt kê tài khoản hoặc dùng aws:PrincipalOrgID | | | Cần aws:SourceArn trong trust policy | | | Cùng Region với log group nguồn | |

Ba lưu ý về lưu trữ: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo tài khoản và ngày | | | Nén GZIP hoặc chuyển Parquet | | | Luật vòng đời sang Glacier cho log cũ | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bucket log nên bật Object Lock | | | Chặn xoá bằng SCP | | | Mã hoá bằng KMS | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | CloudWatch Logs tính theo GB nạp vào | | | Firehose tính theo GB | | | Đặt retention ngắn cho log group nguồn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một dòng thử, đo thời gian tới S3 | | | Kiểm tệp S3 giải nén và đọc được | | | Xem metric ForwardedLogEvents | |

Và một lời khuyên: hãy viết hàm Lambda giải nén ngay khi dựng đường ống, đừng để sau. Log từ CloudWatch tới Firehose là JSON nén lồng nhiều lớp — ghi thẳng ra S3 thì tệp vẫn tới nơi, dung lượng vẫn tăng, mọi chỉ số vẫn xanh, nhưng không công cụ phân tích nào đọc được cho tới khi ai đó thử truy vấn thật.

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

Recently, an Amazon CloudFront distribution has been configured with an Amazon S3 bucket as the origin. However, users are getting an HTTP 307 Temporary Redirect response from Amazon S3.

What could be the reason for this behavior and how will you resolve the issue? (Select two)

  1. A

    Enable Amazon S3 Transfer Acceleration to help CloudFront access data faster over long distances from the S3 bucket
  2. B

    When a new Amazon S3 bucket is created, it takes up to 24 hours before the bucket name propagates across all AWS Regions
  3. C

    CloudFront by default, forwards the requests to the default S3 endpoint. Change the origin domain name of the distribution to include the Regional endpoint of the bucket
  4. D

    Configure CloudFront Cache-Control and Expires headers to a value of zero, to fetch new objects immediately from the S3 bucket
  5. E

    Enable Cross-Region replication for the S3 bucket so that CloudFront can retrieve the data immediately after the creation of the bucket
Xem giải thích

Đáp án

**B và C — Bucket S3 mới tạo cần tới 24 giờ để tên bucket lan truyền qua mọi Region; và CloudFront mặc định chuyển tiếp yêu cầu tới endpoint mặc định của S3 — hãy đổi origin domain name sang endpoint theo Region của bucket.

Vì sao đúng

Mã 307 Temporary Redirect từ S3 có đúng một nguyên nhân, và hai mệnh đề trên là hai mặt của cùng nguyên nhân đó.

⚠ Điểm mấu chốt: 307 là cơ chế chuyển hướng tạm thời của S3 khi DNS chưa lan xong:

Bucket tạo ở `ap-southeast-1`
        ↓
    Yêu cầu đi tới endpoint toàn cục
      `bucket.s3.amazonaws.com`
        ↓
    Bản ghi DNS cho Region đó chưa lan
      xong
        ↓
    S3 trả 307 kèm header `Location`
      trỏ về endpoint đúng Region

⚠ Và CloudFront KHÔNG đi theo chuyển hướng — nó chuyển tiếp cho người dùng:

Origin trả 307
        ↓
    CloudFront không tự gọi lại URL
      mới
        ↓
    Nó trả nguyên 307 về trình duyệt
        ↓
    Trình duyệt đi theo → tới thẳng S3
    → bỏ qua CloudFront hoàn toàn

Hậu quả:
    - không còn cache
    - không còn WAF
    - không còn TLS của CloudFront
    - và với yêu cầu POST/PUT thì
      có thể hỏng hẳn

⚠ Và cách chữa dứt điểm: dùng endpoint theo Region:

Sai:  ten-bucket.s3.amazonaws.com
Đúng: ten-bucket.s3.ap-southeast-1.amazonaws.com

aws cloudfront get-distribution-config --id E1ABC \
  --query 'DistributionConfig.Origins.Items[0].DomainName'

{"Origins": {"Items": [{
   "Id": "S3-kho-anh",
   "DomainName": "kho-anh.s3.ap-southeast-1.amazonaws.com",
   "S3OriginConfig": {"OriginAccessIdentity": ""},
   "OriginAccessControlId": "E2XYZ"}]}}

⚠ Và console của CloudFront giờ đề xuất endpoint Region sẵn:

Chọn bucket từ danh sách thả xuống
        ↓
    Console điền endpoint đầy đủ có
      Region
        ↓
    Vấn đề này thường xảy ra khi gõ
      tay tên miền
    → hoặc khi dựng bằng CloudFormation

⚠ Và 307 cũng xảy ra khi bucket vừa được tạo, dù đã khai đúng Region:

Bucket tạo xong trong vài giây
        ↓
    Nhưng bản ghi DNS cần thời gian
      lan
        ↓
    Trong lúc đó, yêu cầu tới endpoint
      toàn cục nhận 307
        ↓
    Sau 24 giờ thì hết
    → đây chính là mệnh đề B

⚠ Và có ngoại lệ đáng nhớ: us-east-1:

Bucket ở `us-east-1`
        ↓
    Endpoint toàn cục CHÍNH LÀ endpoint
      Region đó
        ↓
    Không bao giờ gặp 307
    → nên lỗi này chỉ lộ ra khi dựng
      ở Region khác

⚠ Và vì sao phương án D không giải quyết gì:

D đặt Cache-Control và Expires bằng 0
        ↓
    Đó là chuyện cache có mới không
        ↓
    307 xảy ra ở tầng phân giải
      endpoint
    → tắt cache chỉ khiến mọi yêu cầu
      đều nhận 307

⚠ Và vì sao phương án A không liên quan:

A bật S3 Transfer Acceleration
        ↓
    Đó là tăng tốc tải lên qua điểm
      biên CloudFront
        ↓
    Nó tạo một endpoint KHÁC
      (`s3-accelerate`)
        ↓
    Không sửa được chuyện phân giải
      Region
    → và còn tính thêm phí

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

E bật Cross-Region Replication
        ↓
    CRR sao chép object sang bucket ở
      Region khác
        ↓
    Nó không rút ngắn thời gian lan
      truyền DNS
        ↓
    Và tạo thêm một bucket phải quản
    → giải pháp cho vấn đề khác hẳn

Bảng ba loại endpoint S3: | Endpoint | Dạng | |---|---| | Toàn cục (legacy) | bucket.s3.amazonaws.com | | Theo Region | bucket.s3.<region>.amazonaws.com | | Website tĩnh | bucket.s3-website-<region>.amazonaws.com |

⚠ Và endpoint website tĩnh KHÁC hẳn endpoint REST: | | REST endpoint | Website endpoint | |---|---|---| | Hỗ trợ HTTPS | có | KHÔNG | | Trang lỗi tuỳ chỉnh | không | có | | Tài liệu mặc định (index.html) | không | có | | Dùng OAC được | có | không |

Cần cả HTTPS lẫn tài liệu mặc định
        ↓
    Dùng REST endpoint + OAC
        ↓
    Rồi thêm CloudFront Function viết
      lại URL kết thúc bằng `/`

⚠ Và OAC là cách hiện đại để CloudFront truy cập S3 riêng tư:

aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name": "oac-kho-anh",
    "OriginAccessControlOriginType": "s3",
    "SigningBehavior": "always",
    "SigningProtocol": "sigv4"}'

Bucket policy tương ứng:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-anh/*",
 "Condition": {"StringEquals": {
   "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABC"}}}

⚠ Và OAC thay thế OAI — khác biệt quan trọng: | | OAI (cũ) | OAC (mới) | |---|---|---| | SSE-KMS | không hỗ trợ | hỗ trợ | | POST, PUT | không | có | | Region mới | không hỗ trợ hết | hỗ trợ | | Trạng thái | kế thừa | khuyến nghị |

⚠ Và chẩn đoán 307 bằng cách gọi thẳng:

curl -sI https://kho-anh.s3.amazonaws.com/anh.jpg | head -5

Thấy `HTTP/1.1 307 Temporary Redirect`
  và header `Location`
        ↓
    Đọc `Location` để biết Region đúng
    → rồi khai chính xác endpoint đó
      trong CloudFront

Ba lợi ích khi khai endpoint Region: | Lợi ích | Chi tiết | |---|---| | Không bao giờ gặp 307 | | | Yêu cầu đi thẳng, ít một chặng | | | Cache của CloudFront hoạt động đúng | |

⚠ Và đây là một trong số ít lỗi mà "chờ 24 giờ" là cách chữa hợp lệ:

Nhưng chờ chỉ chữa triệu chứng
        ↓
    Khai endpoint Region chữa nguyên
      nhân
        ↓
    Và bucket sau cũng không gặp lại
    → làm cả hai

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

  • **D. Đặt Cache-Control và Expires bằng 0 để lấy object mới ngay — đây là phương án gần nhất và thật sự tác động tới hành vi CloudFront, nhưng 307 xảy ra ở tầng phân giải endpoint chứ không phải tầng cache; tắt cache chỉ khiến mọi yêu cầu đều nhận 307.
  • **A. Bật S3 Transfer Acceleration — tăng tốc tải lên qua một endpoint khác, không sửa được việc phân giải Region, lại tính thêm phí.
  • **E. Bật Cross-Region Replication — sao chép object sang Region khác, không rút ngắn thời gian lan truyền DNS.

Ghi nhớ

⚠ Bốn mã chuyển hướng của S3 — bảng phải thuộc: | Mã | Nghĩa | |---|---| | 307 Temporary Redirect | DNS chưa lan, dùng endpoint Region | | 301 Moved Permanently | sai Region trong yêu cầu ký | | 403 Forbidden | thiếu quyền hoặc OAC sai | | 404 Not Found | object không tồn tại hoặc sai tiền tố |

Từ khoá nhận diện:

"HTTP 307 from S3 origin" → dùng regional endpoint "new bucket, 24 hours" → lan truyền DNS "CloudFront can't access private bucket" → OAC + bucket policy "custom error page from S3" → website endpoint, không có HTTPS

Ba lưu ý về endpoint: | Lưu ý | Chi tiết | |---|---| | Luôn khai endpoint theo Region | | | us-east-1 không gặp vấn đề này | | | Website endpoint không hỗ trợ HTTPS | |

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | Thay thế OAI, hỗ trợ SSE-KMS | | | Bucket policy cần AWS:SourceArn | | | Chặn hẳn truy cập trực tiếp vào bucket | |

Ba lưu ý về CloudFront và chuyển hướng: | Lưu ý | Chi tiết | |---|---| | CloudFront không tự đi theo 3xx của origin | | | 3xx được chuyển thẳng cho trình duyệt | | | Cache được 3xx nếu không cấm | |

Ba lưu ý về chẩn đoán: | Lưu ý | Chi tiết | |---|---| | curl -I thẳng vào origin | | | Đọc header X-Cache của CloudFront | | | Bật standard log để thấy mã trả về | |

Ba lưu ý về bucket mới: | Lưu ý | Chi tiết | |---|---| | Tên bucket là toàn cục, duy nhất | | | Xoá rồi tạo lại cùng tên cần chờ | | | Block Public Access bật mặc định | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Origin Shield giảm yêu cầu tới S3 | | | Nén ở CloudFront giảm băng thông | | | Đặt TTL dài cho object bất biến | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl -I vào endpoint origin — không được có 307 | | | Gọi thẳng bucket — phải bị 403 | | | Xem X-Cache: Hit from cloudfront | |

Và một lời khuyên: hãy luôn khai endpoint theo Region trong cấu hình origin, kể cả khi console điền giúp. Lỗi này ẩn rất kỹ: bucket ở us-east-1 không bao giờ gặp nó, nên một mẫu CloudFormation chạy tốt nhiều tháng có thể hỏng ngay lần đầu triển khai sang Region khác.

Câu 458 Design Solutions for Organizational Complexity

A financial services company wants to set up an AWS WAF-based solution to manage AWS WAF rules across multiple AWS accounts that are structured under different Organization Units (OUs) in AWS Organizations. The solution should automatically update and remediate noncompliant AWS WAF rules in all accounts. The solution should also facilitate adding or removing accounts or OUs from managed AWS WAF rule sets as needed.

Which of the following solutions is the most operationally efficient to address the given use case?

  1. A

    Create an AWS Organizations organization-wide AWS Config rule that mandates all resources in the selected OUs to be associated with the AWS WAF rules. Configure automated remediation actions by using AWS Systems Manager Automation documents to fix non-compliant resources. Set up AWS WAF rules by using an AWS CloudFormation stack set to target the same OUs where the AWS Config rule is applied
  2. B

    Use AWS Control Tower to manage AWS WAF rules across accounts in the organization. Leverage AWS Secrets Manager to store account numbers and OUs. Update AWS Secrets Manager as needed to add or remove accounts or OUs. Create cross-account IAM roles in member accounts with permissions to create and update AWS WAF rules. Create a Lambda function to assume IAM roles in the management account to create and update AWS WAF rules in the member accounts
  3. C

    Use AWS Firewall Manager to manage AWS WAF rules across accounts in the organization. Leverage AWS Systems Manager Parameter Store to store account numbers and OUs. Update AWS Systems Manager Parameter Store as needed to add or remove accounts or OUs. Create cross-account IAM roles in member accounts with permissions to create and update AWS WAF rules. Create a Lambda function to assume IAM roles in the management account to create and update AWS WAF rules in the member accounts
  4. D

    Use AWS Security Hub to manage AWS WAF rules across accounts in the organization. Leverage AWS KMS to store account numbers and OUs. Update AWS KMS as needed to add or remove accounts or OUs. Create IAM users in member accounts. Allow AWS Firewall Manager in the management account to use the access key and secret access key to create and update AWS WAF rules in the member accounts
Xem giải thích

Đáp án

**A — Tạo một AWS Config rule áp cho cả tổ chức buộc mọi tài nguyên trong các OU được chọn phải gắn với luật AWS WAF; cấu hình khắc phục tự động bằng SSM Automation document; và triển khai chính luật WAF bằng CloudFormation StackSet nhắm tới cùng các OU đó.

Vì sao đúng

Đề đòi ba thứ, và tổ hợp này lo cả ba: | Yêu cầu | Thành phần | |---|---| | Phát hiện tài nguyên không tuân thủ | Config organization rule | | Tự khắc phục | SSM Automation | | Thêm bớt tài khoản/OU dễ dàng | StackSet theo OU |

⚠ Điểm mấu chốt: StackSet nhắm OU tự lan sang tài khoản mới:

aws cloudformation create-stack-instances \
  --stack-set-name luat-waf \
  --deployment-targets OrganizationalUnitIds=ou-abc-11111111 \
  --regions ap-southeast-1

Thêm tài khoản mới vào OU đó
        ↓
    StackSet tự triển khai vào tài
      khoản mới
        ↓
    Không phải làm gì thêm
    → đúng yêu cầu "thêm/bớt dễ dàng"

Bật tự động triển khai:

aws cloudformation update-stack-set \
  --stack-set-name luat-waf \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

⚠ Và SERVICE_MANAGED là chế độ dùng với Organizations: | Chế độ | Đặc điểm | |---|---| | SELF_MANAGED | tự tạo IAM role ở mỗi tài khoản | | SERVICE_MANAGED | dùng Organizations, tự lan theo OU |

Config rule cấp tổ chức:

aws configservice put-organization-config-rule \
  --organization-config-rule-name bat-buoc-waf \
  --organization-managed-rule-metadata '{
    "RuleIdentifier": "ALB_WAF_ENABLED",
    "ResourceTypesScope": ["AWS::ElasticLoadBalancingV2::LoadBalancer"]}' \
  --excluded-accounts 111122223333

⚠ Và khắc phục tự động gắn vào Config rule:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "bat-buoc-waf",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "GanWebAclVaoAlb",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3,
    "RetryAttemptSeconds": 60,
    "Parameters": {
      "AutomationAssumeRole": {"StaticValue": {"Values": ["<arn-role>"]}},
      "LoadBalancerArn": {"ResourceValue": {"Value": "RESOURCE_ID"}}}}]'

⚠ Và ResourceValue: RESOURCE_ID là cầu nối quan trọng:

Config phát hiện tài nguyên vi phạm
        ↓
    Truyền id tài nguyên đó vào SSM
      document
        ↓
    Document sửa đúng tài nguyên ấy
    → không phải viết logic tìm kiếm

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

⚠ AWS Firewall Manager là dịch vụ được thiết kế đúng cho bài toán này:

Firewall Manager quản WAF, Shield,
  security group, Network Firewall
  trên toàn tổ chức
        ↓
    Tự áp luật cho tài nguyên mới
        ↓
    Tự khắc phục tài nguyên lệch
        ↓
    Nhắm theo OU, theo thẻ
    → đây chính là mô tả của đề bài

Chính sách Firewall Manager:

aws fms put-policy --policy '{
  "PolicyName": "waf-toan-to-chuc",
  "SecurityServicePolicyData": {
    "Type": "WAFV2",
    "ManagedServiceData": "{\"type\":\"WAFV2\",\"preProcessRuleGroups\":[...]}"},
  "ResourceType": "AWS::ElasticLoadBalancingV2::LoadBalancer",
  "RemediationEnabled": true,
  "IncludeMap": {"ORGUNIT": ["ou-abc-11111111"]}}'

⚠ Nhưng phương án C — cái duy nhất nhắc Firewall Manager — lại tự phá hỏng nó:

C nói dùng Firewall Manager
        ↓
    Rồi thêm: Parameter Store lưu số
      tài khoản, IAM role liên tài
      khoản, Lambda tự tạo luật
        ↓
    Toàn bộ phần thêm đó là việc mà
      Firewall Manager LÀM SẴN
    → viết lại bằng tay chính thứ mình
      vừa chọn

Đây là kiểu phương án gài bẫy:
        ↓
    Nhắc đúng dịch vụ
        ↓
    Nhưng mô tả cách dùng sai hoàn
      toàn
    → "hiệu quả vận hành nhất" thì
      không thể là cái này

⚠ Và trong thực tế, Firewall Manager là lựa chọn nên dùng:

Ít việc phải làm hơn Config +
  StackSet
        ↓
    Nhưng đòi:
      - Organizations all features
      - chỉ định tài khoản quản trị
        Firewall Manager
      - bật Config ở mọi tài khoản

aws fms associate-admin-account \
  --admin-account 111122223333

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

B nói Control Tower "quản luật WAF"
        ↓
    Control Tower dựng landing zone và
      guardrail
        ↓
    Nó không quản luật WAF
        ↓
    Và dùng Secrets Manager lưu số tài
      khoản là sai công cụ
    → Secrets Manager để lưu bí mật,
      không phải danh sách cấu hình

⚠ Và vì sao phương án D sai nghiêm trọng hơn cả:

D nói dùng KMS lưu số tài khoản và OU
        ↓
    KMS quản KHOÁ mã hoá
        ↓
    Nó không phải kho cấu hình
        ↓
    Và D còn tạo IAM user với access
      key ở tài khoản thành viên
    → credential dài hạn, ngược hoàn
      toàn với thực hành tốt

Bảng bốn dịch vụ hay bị lẫn: | Dịch vụ | Việc | |---|---| | Firewall Manager | áp chính sách bảo mật mạng toàn tổ chức | | Control Tower | dựng và quản landing zone | | Config | kiểm cấu hình theo luật | | Security Hub | gom phát hiện bảo mật |

⚠ Và StackSet có giới hạn cần biết trước:

Triển khai đồng thời tối đa mặc định
  là 1 tài khoản
        ↓
    Với hàng trăm tài khoản → rất chậm
        ↓
    Chỉnh `MaxConcurrentPercentage`
    → và `FailureTolerancePercentage`

--operation-preferences \
  MaxConcurrentPercentage=25,FailureTolerancePercentage=10

Ba lợi ích của tổ hợp Config + StackSet: | Lợi ích | Chi tiết | |---|---| | Phát hiện và khắc phục tự động | | | Lan theo OU, tài khoản mới tự có | | | Có lịch sử tuân thủ để kiểm toán | |

⚠ Và Config phải bật ở mọi tài khoản mới hoạt động:

Organization config rule chỉ áp được
  cho tài khoản đã bật Config
        ↓
    Tài khoản chưa bật → không xuất
      hiện trong báo cáo
        ↓
    Và im lặng, không báo lỗi
    → dùng chính StackSet để bật Config
      trước

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

  • **C. Dùng Firewall Manager kèm Parameter Store, IAM role liên tài khoản và Lambda tự tạo luật — đây là phương án gần nhất và Firewall Manager thật sự là dịch vụ đúng cho bài toán này, nhưng phần còn lại của phương án viết lại bằng tay đúng những việc Firewall Manager làm sẵn, nên nó là lựa chọn kém hiệu quả vận hành nhất chứ không phải nhất.
  • **B. Control Tower quản luật WAF, Secrets Manager lưu số tài khoản — Control Tower dựng landing zone, không quản WAF; Secrets Manager không phải kho cấu hình.
  • **D. Security Hub quản luật WAF, KMS lưu số tài khoản, IAM user với access key — ba sai lầm: Security Hub chỉ gom phát hiện, KMS quản khoá mã hoá, và credential dài hạn ở tài khoản thành viên là thực hành xấu.

Ghi nhớ

⚠ Bốn cách áp cấu hình lên nhiều tài khoản — bảng phải thuộc: | Cách | Dùng cho | |---|---| | Firewall Manager | WAF, Shield, security group, Network Firewall | | CloudFormation StackSet | bất kỳ tài nguyên nào | | Config organization rule | kiểm tra tuân thủ | | SCP | cấm hành động |

Từ khoá nhận diện:

"WAF rules across accounts, auto-remediate" → Firewall Manager "deploy same resource to an OU" → StackSet nhắm OU "detect non-compliant resources" → Config rule "prevent the action entirely" → SCP

Ba lưu ý về StackSet: | Lưu ý | Chi tiết | |---|---| | SERVICE_MANAGED để nhắm OU | | | auto-deployment cho tài khoản mới | | | Chỉnh MaxConcurrentPercentage cho nhanh | |

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Phải bật ở từng tài khoản | | | Có luật quản lý sẵn, không cần viết | | | Khắc phục qua SSM Automation | |

Ba lưu ý về Firewall Manager: | Lưu ý | Chi tiết | |---|---| | Cần Organizations all features | | | Cần chỉ định tài khoản quản trị | | | Cần Config bật ở mọi tài khoản | |

Ba lưu ý về khắc phục tự động: | Lưu ý | Chi tiết | |---|---| | ResourceValue: RESOURCE_ID truyền id vào | | | Đặt số lần thử tối đa | | | Thử ở môi trường không phải sản xuất trước | |

Ba lưu ý về nơi lưu cấu hình: | Kho | Dùng cho | |---|---| | Parameter Store | cấu hình thường | | Secrets Manager | bí mật có xoay vòng | | KMS | khoá mã hoá, không phải dữ liệu |

Ba lưu ý về quản trị nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Ưu tiên vai trò, không dùng access key | | | Chỉ định delegated administrator | | | Nhắm theo OU chứ đừng liệt kê tài khoản | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thêm một tài khoản vào OU, xem có tự triển khai không | | | Tạo ALB không gắn WAF, xem có bị khắc phục không | | | Đọc báo cáo tuân thủ của Config | |

Và một lời khuyên: hãy bật AWS Config ở mọi tài khoản trước khi dựng organization config rule. Luật cấp tổ chức bỏ qua tài khoản chưa bật Config mà không báo gì — nên báo cáo tuân thủ sẽ hiện toàn màu xanh trong khi những tài khoản chưa cấu hình lại đúng là nơi rủi ro cao nhất.

Câu 459 Design Solutions for Organizational Complexity

A social media company has VPC Flow Logs enabled for its NAT gateway. The security team is seeing Action = ACCEPT for inbound traffic that comes from the public IP address 198.21.200.1 destined for a private EC2 instance. The team must determine whether the traffic represents unsolicited inbound connections from the internet. The first two octets of the VPC CIDR block are 205.1.

Which of the following options can address this requirement?

  1. A

    Inspect the VPC Flow Logs using the CloudTrail console and select the log group that contains the NAT gateway's ENI and the EC2 instance's ENI. Leverage a query filter with the source address set as like 205.1 and the destination address set as like 198.21.200.1. Execute the stats command to filter the sum of bytes transferred by the source address and the destination address
  2. B

    Inspect the VPC Flow Logs using the CloudTrail console and select the log group that contains the NAT gateway's ENI and the EC2 instance's ENI. Leverage a query filter with the destination address set as like 205.1 and the source address set as like 198.21.200.1. Execute the stats command to filter the sum of bytes transferred by the source address and the destination address
  3. C

    Inspect the VPC Flow Logs using the CloudWatch console and select the log group that contains the NAT gateway's ENI and the EC2 instance's ENI. Leverage a query filter with the destination address set as like 205.1 and the source address set as like 198.21.200.1. Execute the stats command to filter the sum of bytes transferred by the source address and the destination address
  4. D

    Inspect the VPC Flow Logs using the CloudWatch console and select the log group that contains the NAT gateway's ENI and the EC2 instance's ENI. Leverage a query filter with the source address set as like 205.1 and the destination address set as like 198.21.200.1. Execute the stats command to filter the sum of bytes transferred by the source address and the destination address
Xem giải thích

Đáp án

**C — Xem VPC Flow Logs bằng console CloudWatch, chọn log group chứa ENI của NAT gateway và ENI của instance; đặt bộ lọc với địa chỉ ĐÍCH giống 205.1 và địa chỉ NGUỒN giống 198.21.200.1; chạy lệnh stats để tính tổng byte theo cặp nguồn–đích.

Vì sao đúng

Câu này có hai trục phân biệt, và phải đúng cả hai: | Trục | Đúng | Sai | |---|---|---| | Công cụ | CloudWatch Logs Insights | CloudTrail | | Chiều | nguồn = IP công khai, đích = VPC | ngược lại |

⚠ Điểm mấu chốt: VPC Flow Logs KHÔNG nằm trong CloudTrail:

CloudTrail ghi LỜI GỌI API
        ↓
    Ai gọi `RunInstances`, `PutObject`...
        ↓
    VPC Flow Logs ghi LƯU LƯỢNG MẠNG
        ↓
    Chúng là hai kho dữ liệu khác hẳn
    → phương án A và B sai ngay ở đây

Bảng phân biệt bốn nguồn log: | Log | Ghi gì | |---|---| | CloudTrail | lời gọi API tới AWS | | VPC Flow Logs | luồng gói tin trong VPC | | CloudWatch Logs | log ứng dụng và hệ thống | | Access log của ELB | yêu cầu HTTP tới bộ cân bằng |

⚠ Và chiều là chỗ dễ sai nhất — đề đang hỏi lưu lượng VÀO:

Đội bảo mật thấy `Action = ACCEPT`
  cho lưu lượng VÀO
        ↓
    Từ IP công khai 198.21.200.1
        ↓
    Tới instance riêng tư trong VPC
      205.1.x.x
        ↓
    → nguồn = 198.21.200.1
    → đích = 205.1.x.x

Phương án A và D đảo ngược:
    nguồn = 205.1, đích = 198.21.200.1
        ↓
    Đó là lưu lượng ĐI RA
        ↓
    Trả lời câu hỏi khác hẳn

Truy vấn Logs Insights đúng:

fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, bytes, action
| filter srcAddr like /198.21.200.1/ and dstAddr like /205.1/
| stats sum(bytes) as tongByte by srcAddr, dstAddr
| sort tongByte desc

⚠ Và câu trả lời cho câu hỏi thật nằm ở việc SO SÁNH hai chiều:

Chỉ nhìn chiều vào thì không kết luận
  được
        ↓
    Phải xem có lưu lượng ĐI RA tương
      ứng trước đó không
        ↓
    Có → đây là phản hồi cho kết nối
      do instance khởi tạo
        ↓
    Không → đây là kết nối vào không
      mời mà tới

Truy vấn chiều ngược để đối chiếu:

fields @timestamp, srcAddr, dstAddr, bytes
| filter srcAddr like /205.1/ and dstAddr like /198.21.200.1/
| stats sum(bytes) as tongByte, count() as soLuong by srcAddr
| sort @timestamp desc

⚠ Và NAT gateway là chi tiết quyết định trong câu này:

Instance nằm trong subnet RIÊNG TƯ
        ↓
    Nó ra Internet qua NAT gateway
        ↓
    NAT gateway là STATEFUL
        ↓
    Nó chỉ cho lưu lượng vào nếu đó là
      PHẢN HỒI cho kết nối do bên
      trong khởi tạo

→ Về mặt lý thuyết, KHÔNG có kết nối
  vào không mời nào đi qua NAT gateway
  được
        ↓
    Nên `ACCEPT` chiều vào ở đây gần
      như chắc chắn là phản hồi
    → nhưng phải chứng minh bằng dữ
      liệu

⚠ Và đó là lý do phải nhìn log của CẢ HAI ENI:

ENI của NAT gateway
        ↓
    Thấy lưu lượng giữa Internet và
      NAT
        ↓
    ENI của instance
        ↓
    Thấy lưu lượng giữa NAT và instance
        ↓
    Ghép hai bên mới thấy toàn cảnh

Đọc một cặp dòng điển hình:

# ENI instance, chiều ra
205.1.3.20  198.21.200.1  51234  443  ACCEPT
# ENI NAT, chiều ra (đã dịch địa chỉ)
52.x.x.x    198.21.200.1  51234  443  ACCEPT
# ENI NAT, chiều vào
198.21.200.1  52.x.x.x    443  51234  ACCEPT
# ENI instance, chiều vào
198.21.200.1  205.1.3.20  443  51234  ACCEPT

Cổng đích chiều vào là cổng phù du
  51234
        ↓
    Cổng nguồn là 443
        ↓
    → rõ ràng là phản hồi cho một
      kết nối HTTPS đi ra

⚠ Và nếu ngược lại thì đó mới là vấn đề:

198.21.200.1  205.1.3.20  40000  22  ACCEPT
        ↓
    Cổng đích là 22, không phải cổng
      phù du
        ↓
    → đây là kết nối VÀO thật
    → và không đi qua NAT gateway được
      → phải có đường vào khác

⚠ Và srcPort là dấu hiệu nhanh nhất để phân biệt: | Dấu hiệu | Kết luận | |---|---| | dstPort là cổng phù du (>32768) | phản hồi | | dstPort là cổng dịch vụ (22, 80, 443) | kết nối vào |

⚠ Và nên thêm trường flow-direction để khỏi phải suy luận:

aws ec2 create-flow-logs \
  --resource-type VPC --resource-ids vpc-abc \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flowlogs \
  --deliver-logs-permission-arn <arn-role> \
  --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${flow-direction} ${traffic-path} ${pkt-src-aws-service} ${pkt-dst-aws-service}'

⚠ Và traffic-path nói cho biết gói tin đi đường nào: | Giá trị | Nghĩa | |---|---| | 1 | qua tài nguyên khác trong cùng VPC | | 2 | qua Internet Gateway hoặc VPC endpoint | | 3 | qua virtual private gateway | | 4 | qua intra-region VPC peering | | 8 | qua Internet gateway của NAT gateway |

Biết đường đi
        ↓
    Không phải đoán từ địa chỉ
    → rất hữu ích khi VPC có nhiều
      cổng ra

⚠ Và Logs Insights có giới hạn phạm vi thời gian:

Truy vấn quét theo khoảng thời gian
  đã chọn
        ↓
    Quét nhiều ngày trên VPC lớn rất
      chậm và tốn
        ↓
    Thu hẹp khoảng thời gian quanh sự
      việc
    → hoặc dùng Athena trên Flow Log
      ghi vào S3

Truy vấn tương đương bằng Athena:

SELECT srcaddr, dstaddr, dstport, SUM(bytes) AS tong_byte
FROM vpc_flow_logs
WHERE srcaddr = '198.21.200.1'
  AND dstaddr LIKE '205.1.%'
  AND day = '2026/09/01'
GROUP BY srcaddr, dstaddr, dstport
ORDER BY tong_byte DESC;

Ba lợi ích của cách này: | Lợi ích | Chi tiết | |---|---| | Dùng đúng kho dữ liệu | | | Lọc đúng chiều đang điều tra | | | stats cho biết quy mô trao đổi | |

⚠ Và tổng byte là chỉ số quan trọng hơn số lượng gói tin:

Vài gói tin nhỏ → có thể là quét cổng
        ↓
    Nhiều byte đi RA → có thể là rò rỉ
      dữ liệu
        ↓
    `stats sum(bytes)` cho thấy điều
      đó ngay

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

  • **D. Dùng console CloudWatch nhưng đặt nguồn = 205.1, đích = 198.21.200.1 — đây là phương án gần nhất và chọn đúng công cụ, nhưng nó lọc chiều đi RA trong khi đề hỏi về lưu lượng VÀO.
  • **B. Dùng console CloudTrail với chiều đúng — chiều lọc đúng nhưng VPC Flow Logs không nằm trong CloudTrail; CloudTrail ghi lời gọi API.
  • **A. Dùng console CloudTrail với chiều sai — sai cả công cụ lẫn chiều.

Ghi nhớ

⚠ Bốn trường quan trọng nhất của Flow Log — bảng phải thuộc: | Trường | Dùng để | |---|---| | srcaddr / dstaddr | xác định chiều | | dstport | cổng dịch vụ hay cổng phù du | | action | ACCEPT hay REJECT | | flow-direction | ingress hay egress, khỏi suy luận |

Từ khoá nhận diện:

"VPC Flow Logs" → CloudWatch Logs hoặc S3, KHÔNG phải CloudTrail "unsolicited inbound" → kiểm dstPort có phải cổng phù du không "who called the API" → CloudTrail "query flow logs at scale" → Athena trên S3

Ba lưu ý về NAT gateway: | Lưu ý | Chi tiết | |---|---| | Stateful — chỉ cho phản hồi vào | | | Không nhận kết nối vào không mời | | | Muốn nhận vào thì cần Internet Gateway | |

Ba lưu ý về Logs Insights: | Lưu ý | Chi tiết | |---|---| | filter trước, stats sau | | | Thu hẹp khoảng thời gian để nhanh và rẻ | | | Lưu truy vấn hay dùng lại | |

Ba lưu ý về định dạng Flow Log: | Lưu ý | Chi tiết | |---|---| | Định dạng mặc định thiếu nhiều trường hữu ích | | | Thêm flow-direction và traffic-path | | | Đổi định dạng không áp cho log cũ | |

Ba lưu ý về nơi lưu: | Đích | Hợp với | |---|---| | CloudWatch Logs | điều tra nhanh, cảnh báo | | S3 | lưu lâu, truy vấn bằng Athena | | Firehose | đẩy sang hệ thống ngoài |

Ba lưu ý về cái Flow Log không ghi: | Không ghi | Chi tiết | |---|---| | DNS tới Amazon Resolver | | | DHCP | | | Metadata service 169.254.169.254 | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo lượng log nạp vào | | | Ghi vào S3 rẻ hơn CloudWatch Logs | | | Bật ở cấp subnet thay vì VPC nếu chỉ cần một phần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối chiếu cả hai chiều cùng cặp IP | | | Xem dstPort chiều vào có phải cổng phù du không | | | Kiểm subnet có Internet Gateway không | |

Và một lời khuyên: hãy nhìn cả hai chiều trước khi kết luận về một dòng ACCEPT. Một mục lưu lượng vào từ IP lạ trông đáng ngờ khi đứng riêng, nhưng nếu vài giây trước đó có một kết nối đi ra tới đúng IP và đúng cổng thì đó chỉ là phản hồi bình thường — và kết luận sai chiều này gây ra rất nhiều báo động giả.

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

A company uses Amazon FSx for Windows File Server with deployment type of Single-AZ 2 as its file storage service for its non-core functions. With a change in the company's policy that mandates high availability of data for all its functions, the company needs to change the existing configuration. The company also needs to monitor the file system activity as well as the end-user actions on the Amazon FSx file server.

Which solutions will you combine to implement these requirements? (Select two)

  1. A

    Configure a new Amazon FSx for Windows file system with a deployment type of Multi-AZ. Transfer data to the newly created file system using the AWS DataSync service. Point all the file system users to the new location. You can test the failover of your Multi-AZ file system by modifying the elastic network interfaces associated with your file system
  2. B

    Configure a new Amazon FSx for Windows file system with a deployment type of Single-AZ 1. Transfer data to the newly created file system using the AWS DataSync service. Point all the file system users to the new location
  3. C

    You can monitor the file system activity using AWS CloudTrail and monitor end-user actions with file access auditing using Amazon CloudWatch Logs
  4. D

    You can monitor storage capacity and file system activity using Amazon CloudWatch, and monitor end-user actions with file access auditing using Amazon CloudWatch Logs and Amazon Kinesis Data Firehose
  5. E

    Configure a new Amazon FSx for Windows file system with a deployment type of Multi-AZ. Transfer data to the newly created file system using the AWS DataSync service. Point all the file system users to the new location. You can test the failover of your Multi-AZ file system by modifying its throughput capacity
Xem giải thích

Đáp án

**D và E — Giám sát dung lượng và hoạt động của hệ thống tệp bằng CloudWatch, giám sát thao tác người dùng cuối bằng file access auditing gửi tới CloudWatch Logs và Amazon Data Firehose; và tạo hệ thống tệp FSx mới kiểu Multi-AZ, chuyển dữ liệu bằng DataSync, trỏ người dùng sang vị trí mới — thử chuyển đổi bằng cách thay đổi throughput capacity.

Vì sao đúng

Đề có hai vế, và mỗi mệnh đề đúng lo một vế: | Vế | Mệnh đề | |---|---| | Sẵn sàng cao | E — dựng Multi-AZ mới + DataSync | | Giám sát hoạt động và thao tác người dùng | D — CloudWatch + file access auditing |

⚠ Điểm mấu chốt thứ nhất: cách chính thức để thử chuyển đổi Multi-AZ là ĐỔI THROUGHPUT CAPACITY:

aws fsx update-file-system \
  --file-system-id fs-abc \
  --windows-configuration ThroughputCapacity=64

Thay đổi throughput capacity
        ↓
    FSx chuyển sang máy chủ dự phòng
        ↓
    Cập nhật máy chính
        ↓
    Chuyển ngược lại
    → hai lần chuyển đổi thật trong
      một thao tác

⚠ Và vì sao mệnh đề A sai — không đụng vào ENI được:

A nói thử chuyển đổi bằng cách sửa
  ENI của hệ thống tệp
        ↓
    ENI của FSx do dịch vụ quản lý
        ↓
    Sửa hoặc xoá chúng có thể làm hệ
      thống tệp KHÔNG KHÔI PHỤC ĐƯỢC
        ↓
    Tài liệu AWS cảnh báo rõ điều này
    → không phải cách thử, mà là cách
      phá

⚠ Và cùng một cảnh báo áp cho nhiều dịch vụ:

ENI của FSx, RDS, ElastiCache,
  Lambda-trong-VPC, VPC endpoint
        ↓
    Đều do dịch vụ tạo và quản
        ↓
    Sửa chúng bằng tay là thao tác
      không được hỗ trợ
    → dấu hiệu nhận biết: chủ sở hữu
      ENI là một service principal

aws ec2 describe-network-interfaces \
  --network-interface-ids eni-abc \
  --query 'NetworkInterfaces[0].{chuSoHuu:RequesterId,mo-ta:Description}'

⚠ Điểm mấu chốt thứ hai: file access auditing gửi tới CloudWatch Logs hoặc Firehose:

aws fsx update-file-system --file-system-id fs-abc \
  --windows-configuration '{
    "AuditLogConfiguration": {
      "FileAccessAuditLogLevel": "SUCCESS_AND_FAILURE",
      "FileShareAccessAuditLogLevel": "SUCCESS_AND_FAILURE",
      "AuditLogDestination": "arn:aws:logs:ap-southeast-1:111122223333:log-group:/aws/fsx/windows"}}'

Hai mức nhật ký kiểm toán: | Mức | Ghi gì | |---|---| | FileAccessAuditLogLevel | truy cập tệp và thư mục | | FileShareAccessAuditLogLevel | truy cập chính chia sẻ |

Bốn giá trị của mỗi mức:

DISABLED           → không ghi
SUCCESS_ONLY       → chỉ ghi thành công
FAILURE_ONLY       → chỉ ghi thất bại
SUCCESS_AND_FAILURE → ghi cả hai

⚠ Và FAILURE_ONLY thường là lựa chọn thực tế nhất:

`SUCCESS_AND_FAILURE` trên hệ thống
  bận
        ↓
    Sinh lượng log khổng lồ
        ↓
    Chi phí CloudWatch Logs tăng vọt
        ↓
    Bắt đầu bằng `FAILURE_ONLY`
    → thấy ngay ai đang bị từ chối
      truy cập

⚠ Và vì sao mệnh đề C sai — CloudTrail không thấy hoạt động tệp:

C nói dùng CloudTrail giám sát hoạt
  động hệ thống tệp
        ↓
    CloudTrail ghi lời gọi API quản trị
        ↓
    `CreateFileSystem`, `UpdateFileSystem`...
        ↓
    Nó KHÔNG thấy ai mở tệp nào
    → đó là việc của file access
      auditing

Bảng phân biệt ba tầng giám sát FSx: | Tầng | Công cụ | Thấy gì | |---|---|---| | Quản trị | CloudTrail | ai tạo/sửa/xoá hệ thống tệp | | Vận hành | CloudWatch metric | dung lượng, IOPS, thông lượng | | Dữ liệu | File access auditing | ai mở/sửa/xoá tệp nào |

Bốn metric CloudWatch cần theo dõi:

FreeStorageCapacity → dung lượng còn
DataReadBytes       → lượng đọc
DataWriteBytes      → lượng ghi
ClientConnections   → số kết nối SMB

Cảnh báo khi sắp hết dung lượng:

aws cloudwatch put-metric-alarm \
  --alarm-name fsx-sap-het-dung-luong \
  --metric-name FreeStorageCapacity \
  --namespace AWS/FSx \
  --dimensions Name=FileSystemId,Value=fs-abc \
  --statistic Minimum --period 300 \
  --threshold 107374182400 --comparison-operator LessThanThreshold \
  --evaluation-periods 2 --alarm-actions <arn-sns>

⚠ Và FSx tăng dung lượng được nhưng không giảm:

`update-file-system` tăng storage
  capacity
        ↓
    Tối thiểu tăng 10% mỗi lần
        ↓
    KHÔNG giảm được
        ↓
    Và phải chờ 6 giờ giữa hai lần
      tăng
    → đừng để tới lúc đầy mới xử lý

⚠ Và vì sao mệnh đề B không đạt yêu cầu:

B tạo hệ thống mới kiểu Single-AZ 1
        ↓
    Đề đòi sẵn sàng cao
        ↓
    Single-AZ 1 còn là thế hệ cũ hơn
      Single-AZ 2 đang dùng
    → đi lùi

Chuyển dữ liệu bằng DataSync:

aws datasync create-task \
  --source-location-arn <arn-fsx-cu> \
  --destination-location-arn <arn-fsx-moi> \
  --options '{
    "VerifyMode": "ONLY_FILES_TRANSFERRED",
    "PreserveDeletedFiles": "REMOVE",
    "SecurityDescriptorCopyFlags": "OWNER_DACL_SACL",
    "TransferMode": "CHANGED"}'

⚠ Và SecurityDescriptorCopyFlags quyết định có giữ được quyền hay không: | Giá trị | Chép gì | |---|---| | NONE | không chép quyền | | OWNER_DACL | chủ sở hữu + quyền truy cập | | OWNER_DACL_SACL | thêm cả cấu hình kiểm toán |

Đang dựng hệ thống có kiểm toán
        ↓
    Phải chép cả SACL
        ↓
    Thiếu → cấu hình kiểm toán trên
      từng thư mục mất sạch

⚠ Và chép SACL đòi quyền đặc biệt:

Tài khoản DataSync dùng phải có
  quyền `SeSecurityPrivilege`
        ↓
    Thường là thành viên nhóm quản
      trị viên miền
        ↓
    Thiếu quyền → tác vụ thất bại với
      lỗi khó hiểu

Ba lợi ích của tổ hợp này: | Lợi ích | Chi tiết | |---|---| | Chuyển đổi tự động khi AZ hỏng | | | Biết ai truy cập tệp nào | | | Cảnh báo trước khi hết dung lượng | |

⚠ Và nên đẩy nhật ký kiểm toán sang Firehose nếu lượng lớn:

CloudWatch Logs: dễ tìm kiếm, đắt
  hơn
        ↓
    Firehose → S3: rẻ hơn nhiều, truy
      vấn bằng Athena
        ↓
    Hệ thống nhiều nghìn người dùng
    → chọn Firehose

⚠ Và tên luồng Firehose phải bắt đầu bằng aws-fsx-:

Giống quy ước `aws-waf-logs-` của WAF
        ↓
    Sai tiền tố → không chọn được luồng
      trong cấu hình
    → và thông báo lỗi không nói rõ lý
      do

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

  • **A. Multi-AZ + DataSync nhưng thử chuyển đổi bằng cách sửa ENI của hệ thống tệp — đây là phương án gần nhất và nửa đầu hoàn toàn đúng, nhưng ENI của FSx do dịch vụ quản lý; sửa chúng là thao tác không được hỗ trợ và có thể làm hệ thống tệp không khôi phục được.
  • **C. Giám sát hoạt động bằng CloudTrail — CloudTrail chỉ ghi lời gọi API quản trị, không thấy được thao tác trên tệp.
  • **B. Tạo hệ thống mới kiểu Single-AZ 1 — không đạt yêu cầu sẵn sàng cao, lại còn là thế hệ cũ hơn cấu hình đang dùng.

Ghi nhớ

⚠ Bốn cách thử chuyển đổi Multi-AZ — bảng phải thuộc: | Cách | Hợp lệ | |---|---| | Đổi throughput capacity | có — cách chính thức | | Cửa sổ bảo trì | có — xảy ra tự nhiên | | Vá hệ điều hành do AWS thực hiện | có | | Sửa hoặc xoá ENI | KHÔNG — có thể phá hỏng |

Từ khoá nhận diện:

"test Multi-AZ failover" → đổi throughput capacity "who accessed which file" → file access auditing "who created the file system" → CloudTrail "storage capacity alerts" → CloudWatch metric FreeStorageCapacity

Ba lưu ý về file access auditing: | Lưu ý | Chi tiết | |---|---| | Đích: CloudWatch Logs hoặc Firehose | | | Tên log group phải bắt đầu /aws/fsx/ | | | Tên luồng Firehose phải bắt đầu aws-fsx- | |

Ba lưu ý về dung lượng: | Lưu ý | Chi tiết | |---|---| | Tăng được, không giảm được | | | Tối thiểu tăng 10% mỗi lần | | | Chờ 6 giờ giữa hai lần tăng | |

Ba lưu ý về DataSync với FSx Windows: | Lưu ý | Chi tiết | |---|---| | SecurityDescriptorCopyFlags giữ quyền NTFS | | | Chép SACL cần SeSecurityPrivilege | | | TransferMode=CHANGED cho lần chạy lại | |

Ba lưu ý về ENI do dịch vụ quản lý: | Lưu ý | Chi tiết | |---|---| | Không sửa, không xoá | | | Nhận biết qua RequesterId | | | Chỉ đổi security group là an toàn | |

Ba lưu ý về chi phí giám sát: | Lưu ý | Chi tiết | |---|---| | SUCCESS_AND_FAILURE sinh log rất lớn | | | Firehose → S3 rẻ hơn CloudWatch Logs | | | Đặt retention cho log group | |

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Hai máy chủ ở hai AZ, sao chép đồng bộ | | | Tên DNS không đổi khi chuyển đổi | | | Đắt khoảng gấp đôi Single-AZ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đổi throughput và đo thời gian gián đoạn | | | Mở một tệp, kiểm log kiểm toán có ghi không | | | So ACL trước và sau khi DataSync chép | |

Và một lời khuyên: hãy bắt đầu file access auditing ở mức FAILURE_ONLY. Bật SUCCESS_AND_FAILURE trên một hệ thống tệp nhiều người dùng sinh ra lượng log đủ để làm hoá đơn CloudWatch Logs vượt cả chi phí của chính hệ thống tệp — và những dòng có giá trị điều tra nhất vẫn luôn là những lần truy cập bị từ chối.