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

Tìm thấy 2194 câu.

Câu 911 AWS Security, Identity, & Compliance

An application running on Amazon ECS processes data and then writes objects to an Amazon S3 bucket. The application requires permissions to make the S3 API calls.

How can a Solutions Architect ensure the application has the required permissions?

  1. A

    Create an IAM role that has read/write permissions to the bucket and update the task definition to specify the role as the taskRoleArn.
  2. B

    Update the S3 policy in IAM to allow read/write access from Amazon ECS, and then relaunch the container.
  3. C

    Attach an IAM policy with read/write permissions to the bucket to an IAM group and add the container instances to the group.
  4. D

    Create a set of Access Keys with read/write permissions to the bucket and update the task credential ID.
Xem giải thích

Đáp án

A — Tạo IAM role có quyền đọc/ghi bucket, và cập nhật task definition khai role đó ở trường taskRoleArn.

Vì sao đúng

Đề hỏi cách cấp quyền cho ứng dụng chạy trong ECS gọi API của S3, và task role là cơ chế chuẩn: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng trong ECS gọi S3 API | task role cấp credential tạm cho container | | Không dùng credential dài hạn | AWS tự luân chuyển |

Task role hoạt động thế nào:

ECS agent lấy credential tạm cho task role
    → phơi bày qua endpoint metadata cục bộ
        ↓
    AWS SDK trong container TỰ TÌM THẤY và dùng
    → không cần đặt access key ở đâu cả

Task definition:

{"family": "ung-dung-xu-ly",
 "taskRoleArn": "arn:aws:iam::123456789012:role/VaiTroTacVuS3",
 "executionRoleArn": "arn:aws:iam::123456789012:role/VaiTroThucThiECS",
 "networkMode": "awsvpc",
 "containerDefinitions": [{
   "name": "ung-dung", "image": "123456789012.dkr.ecr...:latest",
   "memory": 512, "cpu": 256}]}

Trust policy của role:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "ecs-tasks.amazonaws.com"},
   "Action": "sts:AssumeRole"}]}

Permission policy:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Action": ["s3:GetObject", "s3:PutObject"],
   "Resource": "arn:aws:s3:::kho-ket-qua/*"}]}

⚠ Phân biệt hai role trong task definition — điều phải thuộc: | Role | Ai dùng | Việc | |---|---|---| | taskRoleArn (task role) | MÃ TRONG container | gọi API AWS ← câu này | | executionRoleArn (execution role) | ECS agent | kéo ảnh từ ECR, ghi log |

Nhầm hai cái này là lỗi rất phổ biến:
    → cấp quyền S3 cho execution role
    → task chạy được nhưng ứng dụng vẫn AccessDenied

Trong mã không cần làm gì:

import boto3
s3 = boto3.client('s3')      # SDK tự lấy credential từ task role
s3.put_object(Bucket='kho-ket-qua', Key='ket-qua.json', Body=du_lieu)

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

  • **C. Gắn IAM policy vào một IAM group và thêm container instance vào group đó — sai ở hai chỗ: IAM group chỉ chứa IAM user, không chứa instance hay task. Và cấp quyền ở cấp instance nghĩa là mọi container trên máy đó đều có quyền, phá vỡ nguyên tắc đặc quyền tối thiểu.
  • **B. Cập nhật S3 policy trong IAM cho phép "truy cập từ Amazon ECS" rồi khởi động lại container — mô tả mơ hồ và không đúng: IAM policy cấp quyền cho danh tính (user, role), không cấp cho một dịch vụ nói chung. Không có principal nào là "Amazon ECS" theo nghĩa này.
  • **D. Tạo access key và cập nhật "task credential ID" — không có trường nào tên như vậy, và dùng access key dài hạn trong container là thực hành tệ: khoá nằm trong ảnh hoặc biến môi trường, không tự xoay, và rò rỉ là mất quyền vĩnh viễn.

Ghi nhớ

Ba cách cấp quyền AWS cho tải chạy trên AWS — bảng phải thuộc: | Nơi chạy | Cơ chế | |---|---| | EC2 | instance profile (IAM role gắn vào instance) | | ECS task | task role (taskRoleArn) ← câu này | | EKS pod | IRSA hoặc EKS Pod Identity | | Lambda | execution role |

Nguyên tắc gốc:

KHÔNG BAO GIỜ đặt access key dài hạn vào mã, ảnh container, hay biến môi trường. Luôn dùng role — credential tạm thời, tự luân chuyển.

Từ khoá nhận diện:

"ECS task needs to call AWS API" → task role "ECS needs to pull image from ECR" → execution role "EKS pod needs S3 access" → IRSA / Pod Identity

Ba quyền điển hình của execution role: | Quyền | Việc | |---|---| | ecr:GetAuthorizationToken, ecr:BatchGetImage | kéo ảnh | | logs:CreateLogStream, logs:PutLogEvents | ghi log | | secretsmanager:GetSecretValue | tiêm secret vào biến môi trường |

Vế thứ ba là chỗ hay nhầm nhất:

Container cần mật khẩu CSDL từ Secrets Manager
    → khai trong "secrets" của task definition
    → ECS AGENT lấy giá trị và tiêm vào
        ↓
    Nên quyền đó thuộc EXECUTION role, không phải task role

Còn nếu mã tự gọi API Secrets Manager lúc chạy
    → thì quyền thuộc TASK role

{"secrets": [{"name": "DB_PASSWORD",
  "valueFrom": "arn:aws:secretsmanager:...:secret:db-abc:password::"}]}

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Mỗi task definition một role riêng | không dùng chung | | Giới hạn Resource tới đúng bucket và tiền tố | | | Tách quyền đọc và ghi nếu được | |

Giới hạn theo tiền tố:

{"Effect": "Allow", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-ket-qua/ung-dung-a/*"}

⚠ Quyền cấp bucket và cấp object khác nhau:

s3:ListBucket   → Resource là "arn:aws:s3:::kho-ket-qua"   (KHÔNG có /*)
s3:GetObject    → Resource là "arn:aws:s3:::kho-ket-qua/*" (CÓ /*)
        ↓
    Nhầm chỗ này là lỗi AccessDenied khó hiểu nhất với S3

Ba lưu ý cho Fargate: | Lưu ý | Chi tiết | |---|---| | Không có "container instance" nào | mọi quyền qua task role | | Execution role BẮT BUỘC | để kéo ảnh và ghi log | | Cần VPC endpoint nếu ở subnet riêng tư | |

Ba endpoint cần cho Fargate trong subnet riêng tư: | Endpoint | Vì sao | |---|---| | ecr.api và ecr.dkr | xác thực và kéo ảnh | | S3 gateway endpoint | lớp ảnh nằm trong S3 | | logs | ghi CloudWatch Logs |

Thiếu cái thứ hai là lỗi hay gặp:

Có endpoint ECR nhưng thiếu S3 gateway endpoint
    → xác thực ECR thành công
    → tải lớp ảnh thất bại
        ↓
    Task kẹt ở PROVISIONING rồi lỗi

Ba cách kiểm chứng quyền: | Cách | Chi tiết | |---|---| | Chạy aws sts get-caller-identity trong container | xem đang là role nào | | IAM Policy Simulator | thử trước | | CloudTrail | xem lệnh bị từ chối |

# Trong container
curl 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

Đây chính là endpoint mà SDK dùng để lấy credential
    → thấy có credential nghĩa là task role đã gắn đúng

Ba lưu ý về xoay và thu hồi: | Lưu ý | Chi tiết | |---|---| | Credential tạm tự hết hạn | AWS luân chuyển | | Sửa policy có hiệu lực gần như ngay | | | Không có khoá nào để rò rỉ | |

Ba lỗi hay gặp: | Lỗi | Nguyên nhân | |---|---| | AccessDenied dù đã gắn role | nhầm task role với execution role | | AccessDenied với ListBucket | Resource có /* thừa | | Task không khởi động được | execution role thiếu quyền ECR |

Và một lời khuyên: hãy chạy aws sts get-caller-identity trong container khi gặp lỗi phân quyền, trước khi đọc lại policy. Một dòng lệnh cho biết ngay container đang mang danh tính nào — và rất thường xuyên câu trả lời là nó đang dùng execution role, hoặc không mang role nào cả.

Câu 912 AWS Compute

A High Performance Computing (HPC) application will be migrated to AWS. The application requires low network latency and high throughput between nodes and will be deployed in a single AZ.

How should the application be deployed for best inter-node performance?

  1. A

    In a cluster placement group
  2. B

    Behind a Network Load Balancer (NLB)
  3. C

    In a partition placement group
  4. D

    In a spread placement group
Xem giải thích

Đáp án

A — Triển khai trong một cluster placement group.

Vì sao đúng

Đề nêu ba dữ kiện, và cluster placement group là lựa chọn duy nhất: | Dữ kiện | Cách đáp ứng | |---|---| | Tải HPC | cần mạng giữa các node cực nhanh | | Cần ĐỘ TRỄ THẤP và THÔNG LƯỢNG CAO giữa node | cluster placement group đặt máy sát nhau | | Triển khai trong MỘT AZ | cluster placement group vốn nằm trong một AZ |

Ba kiểu placement group — mỗi kiểu một mục đích: | Kiểu | Cách đặt máy | Tối ưu cho | |---|---|---| | Cluster | sát nhau trên cùng rack/lô | độ trễ thấp, thông lượng cao ← câu này | | Partition | nhóm trên các rack riêng biệt | CSDL phân tán lớn (HDFS, Cassandra) | | Spread | mỗi máy một phần cứng riêng | số ít máy quan trọng |

Vì sao cluster cho hiệu năng cao nhất:

Máy đặt sát nhau trong cùng một lô mạng
    → độ trễ giữa node thấp nhất có thể
    → băng thông tới 100 Gbps giữa các instance
        ↓
    Đúng thứ mà tải MPI của HPC cần

Tạo và dùng:

aws ec2 create-placement-group --group-name cum-hpc --strategy cluster

aws ec2 run-instances --image-id ami-abc --count 16   --instance-type c6in.24xlarge   --placement GroupName=cum-hpc   --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa",
    "SubnetId":"subnet-hpc","Groups":["sg-hpc"]}]'

⚠ EFA là mảnh ghép đi kèm bắt buộc với HPC:

Elastic Fabric Adapter (EFA)
    → bỏ qua kernel khi truyền dữ liệu (OS-bypass)
    → độ trễ thấp hơn nhiều so với ENA thường
        ↓
    Placement group đặt máy gần nhau về VẬT LÝ
    EFA làm đường truyền giữa chúng NHANH hơn
    → cần cả hai

Ba lưu ý khi dùng cluster placement group: | Lưu ý | Chi tiết | |---|---| | Chỉ trong MỘT AZ | không trải được | | Nên khởi động HẾT máy cùng lúc | | | Dùng cùng loại instance | |

Vế thứ hai là chi tiết vận hành quan trọng:

Khởi động dần từng máy
    → AWS có thể hết chỗ trong lô đó
    → InsufficientCapacity cho máy sau
        ↓
    Khởi động một lần tất cả, hoặc dùng
    On-Demand Capacity Reservation đặt trước

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

  • **C. Partition placement group — đây là phương án gần nhất vì cũng là placement group, nhưng nó cố ý TÁCH máy ra các rack khác nhau để giảm ảnh hưởng khi một rack hỏng. Điều đó làm tăng độ trễ giữa node — ngược với yêu cầu.
  • **D. Spread placement group — tách còn mạnh hơn: mỗi instance nằm trên một phần cứng riêng biệt. Tối đa hoá khả năng chịu lỗi nhưng độ trễ giữa node cao nhất. Và nó giới hạn 7 instance mỗi AZ.
  • **B. Đặt sau Network Load Balancer — sai vấn đề hoàn toàn: NLB phân phối lưu lượng đi vào từ client. Nó không liên quan gì tới giao tiếp giữa các node trong một cụm tính toán.

Ghi nhớ

Ba placement group — bảng phải thuộc: | Kiểu | Mục tiêu | Giới hạn | |---|---|---| | Cluster | hiệu năng mạng tối đa | một AZ | | Partition | cô lập lỗi theo nhóm | 7 partition mỗi AZ | | Spread | cô lập từng máy | 7 instance mỗi AZ |

Từ khoá nhận diện:

"HPC", "low latency between nodes", "high throughput" → cluster "HDFS, Cassandra, Kafka", "large distributed workload" → partition "small number of critical instances" → spread

Ba đặc điểm của cluster placement group: | Đặc điểm | Chi tiết | |---|---| | Máy trong cùng một lô mạng | | | Băng thông tới 100 Gbps giữa instance | với loại hỗ trợ | | Rủi ro: hỏng phần cứng ảnh hưởng cả nhóm | |

Vế thứ ba là đánh đổi phải chấp nhận:

Đặt máy sát nhau = chúng chia sẻ hạ tầng
    → sự cố phần cứng có thể ảnh hưởng nhiều máy
        ↓
    Với HPC chạy theo đợt thì chấp nhận được
    → với dịch vụ luôn chạy thì không nên

Ba yêu cầu để đạt băng thông cao nhất: | Yêu cầu | Chi tiết | |---|---| | Loại instance hỗ trợ enhanced networking | | | Cùng loại instance trong nhóm | | | Bật EFA nếu dùng MPI | |

Ba đặc điểm của EFA: | Đặc điểm | Chi tiết | |---|---| | OS-bypass — bỏ qua kernel | độ trễ thấp hơn nhiều | | Hỗ trợ libfabric, MPI, NCCL | | | Chỉ dùng được TRONG một subnet | |

Cài EFA:

curl -O https://efa-installer.amazonaws.com/aws-efa-installer-latest.tar.gz
tar -xf aws-efa-installer-latest.tar.gz && cd aws-efa-installer
sudo ./efa_installer.sh -y
fi_info -p efa    # kiểm tra đã nhận chưa

⚠ Security group cho EFA phải cho phép chính nó:

aws ec2 authorize-security-group-ingress --group-id sg-hpc   --protocol -1 --source-group sg-hpc

EFA cần lưu lượng tự do giữa các thành viên trong nhóm
    → thiếu quy tắc self-referencing này thì MPI không chạy

Ba loại instance hay dùng cho HPC: | Họ | Đặc điểm | |---|---| | c6in, c7gn | mạng tới 200 Gbps | | hpc6a, hpc7a | thiết kế riêng cho HPC | | p5, p4d | GPU cho học máy |

Ba lưu ý về khả năng cấp máy: | Lưu ý | Chi tiết | |---|---| | Đặt On-Demand Capacity Reservation trước | | | Khởi động toàn bộ cùng lúc | | | Chuẩn bị phương án AZ khác | |

Ba dịch vụ hỗ trợ HPC: | Dịch vụ | Việc | |---|---| | AWS ParallelCluster | dựng cụm HPC với Slurm tự động | | FSx for Lustre | hệ thống tệp song song | | AWS Batch | xếp lịch job |

ParallelCluster tự lo cả placement group và EFA:

Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: tinh-toan
      Networking:
        SubnetIds: [subnet-hpc]
        PlacementGroup:
          Enabled: true
      ComputeResources:
        - Name: c6in
          InstanceType: c6in.24xlarge
          Efa:
            Enabled: true

Ba lưu ý về placement group và ASG: | Lưu ý | Chi tiết | |---|---| | Khai placement group trong launch template | | | ASG trong cluster group chỉ ở một AZ | | | Cân nhắc rủi ro tập trung | |

Ba lưu ý khác: | Lưu ý | Chi tiết | |---|---| | Không đổi placement group của instance đang chạy | phải dừng máy | | Placement group không tính phí thêm | | | Một instance thuộc tối đa một placement group | |

Đổi placement group:

aws ec2 stop-instances --instance-ids i-abc
aws ec2 modify-instance-placement --instance-id i-abc --group-name cum-hpc
aws ec2 start-instances --instance-ids i-abc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ giữa node | ping, iperf3 | | fi_info -p efa | EFA đã nhận chưa | | Chạy benchmark MPI | OSU benchmark |

Và một lời khuyên: hãy đặt trước năng lực bằng On-Demand Capacity Reservation cho cụm HPC lớn. Cluster placement group đòi hỏi AWS tìm đủ chỗ trống trong cùng một lô mạng, và với vài chục máy loại lớn thì "InsufficientInstanceCapacity" là thông báo bạn sẽ gặp vào đúng lúc đã đặt lịch chạy công việc.

Câu 913 AWS Storage

Objects uploaded to Amazon S3 are initially accessed frequently for a period of 30 days. Then, objects are infrequently accessed for up to 90 days. After that, the objects are no longer needed.

How should lifecycle management be configured?

  1. A

    Transition to REDUCED_REDUNDANCY after 30 days. After 90 days expire the objects
  2. B

    Transition to STANDARD_IA after 30 days. After 90 days transition to ONEZONE_IA
  3. C

    Transition to ONEZONE_IA after 30 days. After 90 days expire the objects
  4. D

    Transition to STANDARD_IA after 30 days. After 90 days transition to GLACIER
Xem giải thích

Đáp án

C — Chuyển sang ONEZONE_IA sau 30 ngày, và hết hạn (expire) sau 90 ngày.

Vì sao đúng

Đề mô tả ba giai đoạn rõ ràng, và quy tắc phải khớp từng cái: | Giai đoạn | Yêu cầu | Cấu hình | |---|---|---| | 0-30 ngày | truy cập thường xuyên | S3 Standard (mặc định) | | 30-90 ngày | truy cập không thường xuyên | ONEZONE_IA | | Sau 90 ngày | KHÔNG CẦN NỮA | expire (xoá) |

Vế thứ ba là điểm phân biệt quan trọng nhất:

"After that, the objects are NO LONGER NEEDED"
        ↓
    Không cần nữa = XOÁ, không phải chuyển sang lớp lưu trữ khác
    → chuyển sang Glacier là vẫn TRẢ TIỀN cho thứ không dùng

Đây là điều loại phương án B và D.

Cấu hình:

{"Rules": [{
  "ID": "vong-doi-90-ngay",
  "Status": "Enabled",
  "Filter": {},
  "Transitions": [{"Days": 30, "StorageClass": "ONEZONE_IA"}],
  "Expiration": {"Days": 90}}]}

aws s3api put-bucket-lifecycle-configuration --bucket kho-du-lieu   --lifecycle-configuration file://vong-doi.json

Vì sao ONEZONE_IA hợp lý ở đây:

Dữ liệu chỉ sống thêm 60 ngày rồi bị xoá
    → không phải dữ liệu cần bảo tồn lâu dài
        ↓
    ONEZONE_IA rẻ hơn STANDARD_IA khoảng 20%
    → đánh đổi: chỉ lưu trong MỘT AZ

⚠ Và mốc 30 ngày không phải lựa chọn tuỳ ý:

S3 lifecycle KHÔNG cho chuyển từ Standard sang
    STANDARD_IA hoặc ONEZONE_IA trước 30 NGÀY
        ↓
    Đề nói "30 ngày đầu truy cập thường xuyên"
    → con số khớp đúng giới hạn kỹ thuật

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Rẻ nhất cho giai đoạn 30-90 ngày | | | Tự động xoá — không tích tụ chi phí | | | Một quy tắc, không cần script nào | |

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

  • **D. Chuyển sang STANDARD_IA sau 30 ngày, rồi sang GLACIER sau 90 ngày — đây là phương án gần nhất vì đúng mốc thời gian và đúng cơ chế, nhưng nó giữ lại dữ liệu không còn cần: đề nói rõ sau 90 ngày object "no longer needed", nên chuyển sang Glacier là tiếp tục trả tiền cho thứ vô dụng. Và STANDARD_IA đắt hơn ONEZONE_IA.
  • **B. Chuyển sang STANDARD_IA sau 30 ngày, rồi sang ONEZONE_IA sau 90 ngày — cùng vấn đề giữ lại dữ liệu, và còn chuyển sai hướng: sau 90 ngày lẽ ra phải xoá, không phải chuyển sang một lớp vẫn tính phí.
  • **A. Chuyển sang REDUCED_REDUNDANCY sau 30 ngày rồi xoá sau 90 — đúng ở vế xoá, nhưng RRS là lớp lưu trữ đã lỗi thời: AWS không còn khuyến nghị, và nó đắt hơn STANDARD_IA trong khi độ bền thấp hơn.

Ghi nhớ

Bảng lớp lưu trữ S3 — phải thuộc: | Lớp | Số AZ | Lưu tối thiểu | Giá tương đối | |---|---|---|---| | Standard | ≥ 3 | — | 1,0× | | Standard-IA | ≥ 3 | 30 ngày | ~0,55× | | One Zone-IA | 1 ⚠ | 30 ngày | ~0,44× | | Glacier Instant Retrieval | ≥ 3 | 90 ngày | ~0,2× | | Glacier Flexible Retrieval | ≥ 3 | 90 ngày | ~0,16× | | Deep Archive | ≥ 3 | 180 ngày | ~0,04× | | Reduced Redundancy | ≥ 3 | — | lỗi thời |

⚠ Ba giới hạn lifecycle phải nhớ: | Giới hạn | Con số | |---|---| | Standard → Standard-IA / One Zone-IA | tối thiểu 30 ngày | | Object < 128 KB | không chuyển sang IA | | Đã ở IA → Glacier | không còn ràng buộc 30 ngày |

Từ khoá nhận diện:

"no longer needed after X" → Expiration, không phải Transition "can be recreated", "not critical" → One Zone-IA "must be highly available" → Standard-IA (≥ 3 AZ) "archive for years" → Glacier hoặc Deep Archive

Khi nào One Zone-IA hợp lý: | Trường hợp | Vì sao | |---|---| | Dữ liệu tạo lại được | thumbnail, bản chuyển mã | | Bản sao thứ hai | đã có bản gốc nơi khác | | Vòng đời ngắn | ← câu này |

Và khi nào KHÔNG nên:

Dữ liệu duy nhất, không tạo lại được
    → AZ mất là mất vĩnh viễn
        ↓
    Tiết kiệm 20% không đáng với rủi ro đó

Ba loại hành động trong lifecycle: | Hành động | Việc | |---|---| | Transitions | chuyển lớp lưu trữ | | Expiration | XOÁ object | | AbortIncompleteMultipartUpload | dọn phần tải lên dở |

⚠ Quy tắc thứ ba nên có ở MỌI bucket:

{"Rules": [{"ID":"don-multipart-do","Status":"Enabled","Filter":{},
  "AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}]}

Multipart upload thất bại giữa chừng
    → các phần đã tải lên VẪN TÍNH PHÍ
    → KHÔNG hiện trong danh sách object
        ↓
    Chi phí ẩn tích tụ nhiều năm mà không ai thấy

Ba lưu ý với bucket bật versioning: | Lưu ý | Chi tiết | |---|---| | Expiration chỉ tạo delete marker | phiên bản cũ vẫn còn | | Cần NoncurrentVersionExpiration | để xoá thật | | Và ExpiredObjectDeleteMarker | dọn delete marker mồ côi |

{"Rules": [{"ID":"don-day-du","Status":"Enabled","Filter":{},
  "Expiration":{"Days":90,"ExpiredObjectDeleteMarker":true},
  "NoncurrentVersionExpiration":{"NoncurrentDays":30}}]}

Vế đầu là bẫy chi phí lớn:

Bucket bật versioning, lifecycle chỉ có Expiration
    → object "biến mất" khỏi danh sách
    → nhưng mọi phiên bản cũ VẪN TÍNH PHÍ
        ↓
    Dung lượng bucket không giảm chút nào

Ba lưu ý về thời điểm áp dụng: | Lưu ý | Chi tiết | |---|---| | Lifecycle chạy theo lô, mỗi ngày một lần | | | Có thể trễ so với mốc chính xác | | | Không tính phí cho việc xoá do lifecycle | |

Ba khoản chi phí liên quan: | Khoản | Chi tiết | |---|---| | Phí chuyển lớp theo SỐ đối tượng | | | Phí lưu tối thiểu nếu xoá sớm | | | Xoá do Expiration: miễn phí | |

Ba công cụ phân tích: | Công cụ | Việc | |---|---| | S3 Storage Lens | phân bố tuổi và kích thước | | S3 Storage Class Analysis | gợi ý thời điểm chuyển | | Cost Explorer | chi phí theo lớp |

Ba lưu ý khi lọc: | Lưu ý | Chi tiết | |---|---| | Filter rỗng = áp cho MỌI object | | | Lọc theo tiền tố cho từng thư mục | | | Lọc theo tag cho từng loại dữ liệu | |

Và một lời khuyên: hãy thêm quy tắc AbortIncompleteMultipartUpload vào mọi bucket ngay hôm nay. Đó là khoản chi phí ẩn phổ biến nhất của S3 — các phần tải lên dở không hiện trong danh sách object, không hiện trong dung lượng bucket bạn nhìn thấy, nhưng vẫn xuất hiện đều đặn trong hoá đơn mỗi tháng.

Câu 914 AWS Database

A company runs an eCommerce application that uses an Amazon Aurora database. The database performs well except for short periods when monthly sales reports are run. A Solutions Architect has reviewed metrics in Amazon CloudWatch and found that the Read Ops and CPUUtilization metrics are spiking during the periods when the sales reports are run.

What is the MOST cost-effective solution to solve this performance issue?

  1. A

    Create an Amazon Redshift data warehouse and run the reporting there.
  2. B

    Create an Aurora Replica and use the replica endpoint for reporting.
  3. C

    Enable storage Auto Scaling for the Amazon Aurora database.
  4. D

    Modify the Aurora database to use an instance class with more CPU.
Xem giải thích

Đáp án

B — Tạo một Aurora Replica và dùng reader endpoint cho việc chạy báo cáo.

Vì sao đúng

Đề nêu bốn dữ kiện, và Aurora Replica là lời giải trực tiếp nhất: | Dữ kiện | Ý nghĩa | |---|---| | CSDL chạy tốt TRỪ lúc chạy báo cáo tháng | vấn đề chỉ ở một loại tải | | ReadOps và CPUUtilization tăng vọt | tải ĐỌC là nguyên nhân | | Đang dùng Aurora | Aurora Replica có sẵn | | TIẾT KIỆM NHẤT | thêm một replica, không đổi kiến trúc |

Vì sao tách replica là đúng cách:

Báo cáo tháng quét lượng dữ liệu lớn
    → chiếm CPU và I/O của instance chính
    → giao dịch thương mại điện tử bị chậm theo
        ↓
    Tách sang replica: hai tải chạy trên hai máy
    → ảnh hưởng lẫn nhau gần như bằng không

Tạo replica:

aws rds create-db-instance --db-instance-identifier replica-bao-cao   --db-cluster-identifier cum-thuong-mai   --db-instance-class db.r6g.2xlarge   --engine aurora-postgresql --promotion-tier 15

Và trỏ báo cáo vào reader endpoint:

cum-thuong-mai.cluster-ro-abc123.ap-southeast-1.rds.amazonaws.com

⚠ --promotion-tier 15 là chi tiết đáng chú ý:

Tier cao = ít được chọn làm writer khi failover
    → replica báo cáo không bị đôn lên làm instance chính
        ↓
    Vì nếu nó thành writer, tải báo cáo nặng
    sẽ chạy trên chính máy phục vụ giao dịch

Vì sao Aurora Replica rẻ và nhanh: | Đặc điểm | Chi tiết | |---|---| | Chia sẻ CÙNG tầng lưu trữ với writer | không nhân đôi dung lượng | | Độ trễ sao chép thường < 100 ms | | | Thêm và xoá trong vài phút | |

Vế đầu là điểm khác biệt lớn với RDS thường:

RDS read replica: nhân bản DỮ LIỆU qua binlog
    → tốn thêm dung lượng lưu trữ
    → độ trễ tính bằng giây

Aurora Replica: đọc CÙNG một tầng lưu trữ
    → chỉ trả tiền instance, không trả thêm lưu trữ
    → độ trễ mili giây

Và có cách tiết kiệm hơn nữa:

Báo cáo chỉ chạy vài giờ mỗi THÁNG
    → tạo replica trước khi chạy, xoá sau khi xong
        ↓
    Chỉ trả tiền vài giờ thay vì cả tháng

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

  • **D. Đổi sang instance class nhiều CPU hơn — đây là phương án gần nhất vì thực sự giải quyết được triệu chứng, nhưng nó đắt hơn nhiều: bạn nâng cấp instance chính và trả tiền cho cấu hình lớn đó suốt 24/7, trong khi vấn đề chỉ xảy ra vài giờ mỗi tháng. Và hai tải vẫn tranh nhau tài nguyên.
  • **A. Dựng Amazon Redshift để chạy báo cáo ở đó — kiến trúc đúng cho phân tích quy mô lớn, nhưng quá mức và tốn kém cho bài này: phải dựng cụm, phải xây quy trình ETL, và phải viết lại truy vấn theo phương ngữ Redshift.
  • **C. Bật storage auto scaling cho Aurora — sai vấn đề hoàn toàn: metric tăng vọt là ReadOps và CPUUtilization, không phải dung lượng lưu trữ. Aurora vốn đã tự mở rộng lưu trữ tới 128 TB.

Ghi nhớ

Nguyên tắc gốc:

Tải phân tích và tải giao dịch nên chạy trên máy khác nhau. Đó là cách rẻ hơn và hiệu quả hơn việc nâng cấp một máy để gánh cả hai.

Từ khoá nhận diện:

"ReadOps spike" + "reporting" + "cost-effective" → read replica / Aurora Replica "same query repeated" → ElastiCache "petabyte analytics, complex joins" → Redshift "connection exhaustion" → RDS Proxy

⚠ Aurora Replica và RDS Read Replica — bảng phân biệt: | | Aurora Replica | RDS Read Replica | |---|---|---| | Cơ chế | chia sẻ tầng lưu trữ | sao chép qua binlog | | Độ trễ | < 100 ms | giây | | Dung lượng thêm | không | nhân đôi | | Số lượng tối đa | 15 | 5 | | Failover | tự động | thủ công (promote) |

Bốn loại endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance chính hiện tại | | Reader | cân bằng qua MỌI replica ← câu này | | Custom | nhóm instance tự chọn | | Instance | một instance cụ thể |

Custom endpoint là nâng cấp tự nhiên khi có nhiều replica:

aws rds create-db-cluster-endpoint --db-cluster-identifier cum-thuong-mai   --db-cluster-endpoint-identifier bao-cao --endpoint-type READER   --static-members replica-bao-cao

Reader endpoint trải trên MỌI replica
    → nếu có replica khác phục vụ ứng dụng
    → truy vấn báo cáo có thể rơi vào đó
        ↓
    Custom endpoint gom đúng replica dành cho báo cáo

Ba đặc điểm của reader endpoint: | Đặc điểm | Chi tiết | |---|---| | Cân bằng qua DNS round-robin | | | Chỉ gồm replica, không gồm writer | | | Replica mới tự vào | |

⚠ Cân bằng qua DNS có hạn chế:

Cân bằng xảy ra lúc PHÂN GIẢI DNS
    → connection pool giữ kết nối lâu
    → mọi truy vấn dồn vào một replica
        ↓
    Với báo cáo chạy theo đợt thì ít ảnh hưởng
    → nhưng cần biết khi có nhiều replica

Ba lưu ý về promotion tier: | Tier | Ý nghĩa | |---|---| | 0 | được chọn làm writer trước tiên | | 1-15 | ưu tiên giảm dần | | — | cùng tier thì chọn máy lớn nhất |

Ba lưu ý về truy vấn báo cáo trên replica: | Lưu ý | Chi tiết | |---|---| | Đặt statement_timeout cho tài khoản báo cáo | | | Cấu hình parameter group riêng nếu cần | | | Theo dõi AuroraReplicaLag | |

ALTER ROLE bao_cao SET statement_timeout = '2h';
ALTER ROLE bao_cao SET work_mem = '256MB';

Ba cách tiết kiệm thêm: | Cách | Chi tiết | |---|---| | Tạo replica trước khi chạy, xoá sau | báo cáo tháng | | Aurora Serverless v2 làm replica | tự co giãn | | Aurora clone cho phân tích tách hẳn | |

Aurora clone rất rẻ nhờ copy-on-write:

aws rds restore-db-cluster-to-point-in-time   --source-db-cluster-identifier cum-thuong-mai   --db-cluster-identifier cum-bao-cao --restore-type copy-on-write   --use-latest-restorable-time

Chỉ trả tiền cho phần dữ liệu THAY ĐỔI sau khi clone
    → clone một cụm 10 TB gần như miễn phí lúc đầu
        ↓
    Nhưng dữ liệu ĐÓNG BĂNG tại thời điểm clone
    → hợp với báo cáo tháng (chốt số liệu)

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | AuroraReplicaLag | độ trễ dữ liệu | | CPUUtilization theo instance | tải đã tách chưa | | ReadIOPS | |

Ba lưu ý về chi phí Aurora: | Khoản | Chi tiết | |---|---| | Replica tính phí instance đầy đủ | | | Lưu trữ KHÔNG nhân lên | | | Cân nhắc I/O-Optimized nếu I/O > 25% hoá đơn | |

Và một lời khuyên: hãy đặt promotion tier cao cho replica dành riêng cho báo cáo. Một lần failover bình thường có thể biến chính máy chạy báo cáo thành instance ghi của hệ thống bán hàng — và khi đó bạn có đúng vấn đề ban đầu, chỉ khác là nó xảy ra vào lúc bạn ít ngờ nhất.

Câu 915 AWS Security, Identity, & Compliance

To accelerate experimentation and agility, a company allows developers to apply existing IAM policies to existing IAM roles. Nevertheless, the security operations team is concerned that the developers could attach the existing administrator policy, circumventing any other security policies.

How should a solutions architect address this issue?

  1. A

    Set a permissions boundary on the developer IAM role that denies attaching administrator access.
  2. B

    Assign all IAM duties to the security operations team and prevent developers from attaching policies.
  3. C

    Disable IAM activity across all organizational accounts using service control policies.
  4. D

    Send an alert every time a developer creates a new policy using an Amazon SNS topic.
Xem giải thích

Đáp án

A — Đặt permissions boundary trên IAM role của lập trình viên, từ chối việc gắn quyền administrator.

Vì sao đúng

Đề nêu hai mục tiêu đối nghịch, và permissions boundary hoà giải được: | Mục tiêu | Cách đáp ứng | |---|---| | Lập trình viên tự gắn policy để làm nhanh | vẫn cho phép thao tác IAM | | Nhưng KHÔNG được leo lên quyền admin | trần quyền không vượt được |

Permissions boundary hoạt động thế nào:

Boundary KHÔNG cấp quyền — nó đặt TRẦN
        ↓
    Quyền thật = GIAO của (identity policy) và (boundary)
        ↓
    Gắn AdministratorAccess vào role
    → chính sách đó tồn tại
    → nhưng quyền hiệu lực vẫn bị boundary cắt
    → gắn được mà KHÔNG dùng được

Boundary policy:

{"Version": "2012-10-17",
 "Statement": [
   {"Sid": "TranQuyenChoPhep",
    "Effect": "Allow",
    "Action": ["ec2:*", "s3:*", "lambda:*", "logs:*", "dynamodb:*"],
    "Resource": "*"},
   {"Sid": "BuocRoleMoiCungMangBoundary",
    "Effect": "Deny",
    "Action": ["iam:CreateRole", "iam:PutRolePolicy", "iam:AttachRolePolicy"],
    "Resource": "*",
    "Condition": {"StringNotEquals":
      {"iam:PermissionsBoundary":
       "arn:aws:iam::123456789012:policy/RanhGioiDev"}}},
   {"Sid": "CamGoBoundary",
    "Effect": "Deny",
    "Action": ["iam:DeleteRolePermissionsBoundary",
               "iam:DeleteUserPermissionsBoundary"],
    "Resource": "*"}]}

Ba câu lệnh, ba vai trò: | Câu | Việc | |---|---| | Allow danh sách dịch vụ | định nghĩa trần quyền | | Deny tạo role không kèm boundary | chống lách bằng role mới | | Deny gỡ boundary | chống tự cởi trói |

Gắn boundary:

aws iam put-role-permissions-boundary --role-name RoleLapTrinhVien   --permissions-boundary arn:aws:iam::123456789012:policy/RanhGioiDev

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Giữ được tốc độ thử nghiệm | lập trình viên vẫn tự làm | | Trần quyền không vượt được | | | Uỷ quyền IAM an toàn | |

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

  • **C. Dùng SCP tắt hoạt động IAM trên toàn bộ tài khoản trong tổ chức — đây là phương án gần nhất về mặt cơ chế giới hạn, nhưng nó quá tay: tắt IAM nghĩa là lập trình viên không tạo được role cho Lambda, không gắn được policy nào. Chính điều mà đề muốn giữ lại bị phá bỏ.
  • **B. Giao toàn bộ việc IAM cho đội bảo mật và cấm lập trình viên gắn policy — an toàn nhưng triệt tiêu mục tiêu đầu tiên của đề: mọi thay đổi quyền phải qua một hàng đợi yêu cầu, và đội bảo mật thành nút thắt.
  • **D. Gửi cảnh báo qua SNS mỗi khi có policy mới — đây là phát hiện SAU sự việc, không phải ngăn chặn. Quyền admin đã được cấp và có thể đã bị sử dụng trước khi ai đó đọc email.

Ghi nhớ

Ba cơ chế giới hạn quyền — bảng phải thuộc: | Cơ chế | Phạm vi | Cấp quyền? | |---|---|---| | SCP | cả tài khoản / OU | ❌ chỉ giới hạn | | Permissions boundary | một user hoặc role | ❌ chỉ giới hạn | | Identity policy | user, group, role | ✅ |

Công thức quyền hiệu lực:

Quyền thật = SCP ∩ Permissions Boundary ∩ Identity Policy ∩ (Resource Policy)
        ↓
    Deny ở BẤT KỲ tầng nào đều thắng

Từ khoá nhận diện:

"developers attach policies but must not escalate" → permissions boundary "restrict all accounts in an OU" → SCP "delegate IAM administration safely" → permissions boundary

⚠ Ba lỗ hổng thường gặp khi uỷ quyền IAM: | Lỗ hổng | Cách chặn | |---|---| | Tạo role mới không boundary rồi gắn admin | điều kiện iam:PermissionsBoundary | | Gỡ boundary của chính mình | Deny DeleteRolePermissionsBoundary | | Tạo IAM user mới với quyền cao | Deny CreateUser hoặc buộc kèm boundary |

Vế đầu là lỗ hổng làm vô hiệu toàn bộ cơ chế:

Boundary chỉ chặn role hiện tại
    → lập trình viên tạo role MỚI không boundary
    → gắn AdministratorAccess vào role đó
    → rồi assume role đó
        ↓
    Toàn bộ hàng rào bị đi vòng bằng ba lệnh CLI

⚠ Ba điều permissions boundary KHÔNG làm: | Điều | Chi tiết | |---|---| | Không cấp quyền | chỉ giới hạn | | Không áp cho resource-based policy | bucket policy vẫn cấp được | | Không áp cho service-linked role | |

Vế thứ hai đáng nhớ:

Boundary chặn s3:* của role
    → nhưng bucket policy cấp thẳng quyền cho ARN role đó
    → truy cập vẫn thành công
        ↓
    Vì resource-based policy được đánh giá độc lập

Ba thao tác IAM nguy hiểm cần chặn: | Thao tác | Rủi ro | |---|---| | iam:AttachRolePolicy với AdministratorAccess | | | iam:PassRole không giới hạn | truyền role quyền cao cho dịch vụ | | iam:UpdateAssumeRolePolicy | mở role cho người ngoài |

PassRole là lỗ hổng leo thang kinh điển:

{"Effect": "Allow", "Action": "iam:PassRole",
 "Resource": "arn:aws:iam::123456789012:role/VaiTroChoLambda*"}

Không giới hạn Resource của PassRole
    → lập trình viên tạo Lambda và gán role admin cho nó
    → Lambda chạy với quyền admin
        ↓
    Luôn giới hạn PassRole tới đúng tiền tố role được phép

Ba cách kiểm chứng: | Cách | Công cụ | |---|---| | IAM Policy Simulator | thử trước khi áp | | IAM Access Analyzer | tìm quyền dư và truy cập ngoài | | CloudTrail | xem thao tác bị từ chối |

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Thử ở tài khoản dev trước | | | Có quy trình xin nới trần | | | Ghi tài liệu vì sao chặn từng thứ | |

Vế thứ hai quan trọng hơn nhiều người nghĩ:

Boundary quá chặt mà không có đường xin nới
    → lập trình viên tìm cách lách
    → hoặc dùng tài khoản cá nhân
        ↓
    Bảo mật thất bại theo cách tệ nhất

Ba tầng nên dùng cùng nhau: | Tầng | Việc | |---|---| | SCP | trần cho cả tài khoản/OU | | Permissions boundary | trần cho từng role | | Identity policy | quyền thực tế |

Ba dấu hiệu leo thang đặc quyền cần cảnh báo: | Dấu hiệu | Chi tiết | |---|---| | Gắn AdministratorAccess | | | Tạo access key cho user khác | | | Sửa trust policy của role | |

Ba việc kiểm chứng sau khi áp: | Việc | Cách | |---|---| | Thử gắn AdministratorAccess | phải gắn được mà không dùng được | | Thử tạo role không boundary | phải bị từ chối | | Thử gỡ boundary | phải bị từ chối |

Và một lời khuyên: hãy kiểm chứng cả ba lỗ hổng lách trước khi coi là xong — tạo role mới, gỡ boundary, và PassRole. Một permissions boundary chỉ chặn được đúng những gì nó liệt kê, và cơ chế trông rất chặt cho tới khi ai đó thử đúng ba lệnh mà nó quên nhắc tới.

Câu 916 AWS Security, Identity, & Compliance

A company runs workloads in the AWS Cloud and wants to consolidate and analyze security-related information to enhance workload protection. The company needs a solution that simplifies the collection and centralization of security data across multiple AWS accounts and Regions with minimal development effort.

Which solution will meet these requirements with the LEAST development effort?

  1. A

    Configure Amazon Security Lake to automatically collect, normalize, and store security data in Amazon S3 for analysis.
  2. B

    Use AWS Glue crawlers to extract and catalog security data into an AWS Lake Formation-managed data lake.
  3. C

    Create a custom Lambda function to fetch security data in JSON format and store it in Amazon S3 for further analysis.
  4. D

    Deploy an Amazon RDS cluster and use AWS Database Migration Service (AWS DMS) to load security data from multiple sources.
Xem giải thích

Đáp án

A — Cấu hình Amazon Security Lake để tự động thu thập, chuẩn hoá và lưu dữ liệu bảo mật vào Amazon S3 cho việc phân tích.

Vì sao đúng

Đề nêu bốn yêu cầu, và Security Lake là dịch vụ được thiết kế chính xác cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Gom dữ liệu bảo mật tập trung | Security Lake là hồ dữ liệu bảo mật | | Từ NHIỀU tài khoản và NHIỀU vùng | tích hợp Organizations, gom đa vùng | | Chuẩn hoá để phân tích được | tự chuyển sang chuẩn OCSF | | ÍT công phát triển nhất | bật bằng cấu hình, không viết mã |

Vì sao chuẩn hoá là phần khó nhất — và Security Lake làm sẵn:

CloudTrail, VPC Flow Logs, Route 53 logs, GuardDuty...
    → mỗi nguồn một định dạng khác nhau
        ↓
    Muốn truy vấn chung phải viết ETL cho từng nguồn
    → đó chính là "development effort" mà đề muốn tránh
        ↓
    Security Lake tự chuyển hết sang OCSF

OCSF là gì:

Open Cybersecurity Schema Framework
    → chuẩn mở cho sự kiện bảo mật
        ↓
    Mọi nguồn đều có cùng tên trường
    → một truy vấn dùng được cho mọi loại log

Bật Security Lake:

aws securitylake create-data-lake   --configurations '[{"region":"ap-southeast-1",
    "encryptionConfiguration":{"kmsKeyId":"alias/khoa-bao-mat"},
    "lifecycleConfiguration":{"transitions":[
      {"storageClass":"STANDARD_IA","days":30},
      {"storageClass":"GLACIER","days":90}],
      "expiration":{"days":730}}}]'   --meta-store-manager-role-arn <arn-role>

aws securitylake create-aws-log-source   --sources '[{"regions":["ap-southeast-1","us-east-1"],
    "sourceName":"CLOUD_TRAIL_MGMT","sourceVersion":"2.0"},
    {"regions":["ap-southeast-1"],"sourceName":"VPC_FLOW"},
    {"regions":["ap-southeast-1"],"sourceName":"SH_FINDINGS"}]'

Nguồn dữ liệu tích hợp sẵn: | Nguồn | Nội dung | |---|---| | CloudTrail (management và data events) | ai làm gì | | VPC Flow Logs | lưu lượng mạng | | Route 53 Resolver query logs | truy vấn DNS | | Security Hub findings | phát hiện tổng hợp | | EKS audit logs | | | AWS WAF logs | |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu ở dạng Parquet phân vùng sẵn | truy vấn Athena rẻ | | Vòng đời lưu trữ có sẵn | tự chuyển tầng | | Chia sẻ cho đội phân tích qua subscriber | |

Truy vấn bằng Athena:

SELECT actor.user.name, api.operation, count(*) AS so_lan
FROM amazon_security_lake_table_ap_southeast_1_cloud_trail_mgmt_2_0
WHERE eventday >= '20260801' AND api.response.error IS NOT NULL
GROUP BY 1, 2 ORDER BY so_lan DESC LIMIT 20;

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

  • **B. Dùng Glue crawler trích xuất và lập danh mục vào Lake Formation — đây là phương án gần nhất và thực sự dựng được một hồ dữ liệu, nhưng bạn phải tự làm phần khó nhất: viết job ETL chuẩn hoá từng định dạng log, tự lo gom từ nhiều tài khoản và vùng, tự quản lý phân vùng. Đó chính là công việc mà Security Lake đã đóng gói sẵn.
  • **C. Viết Lambda tuỳ chỉnh lấy dữ liệu bảo mật dạng JSON và lưu vào S3 — công phát triển cao nhất: phải viết và bảo trì mã cho từng nguồn, từng tài khoản, từng vùng, cộng xử lý lỗi và giám sát.
  • **D. Dựng cụm RDS và dùng DMS nạp dữ liệu bảo mật — sai loại kho dữ liệu: log bảo mật là dữ liệu khối lượng lớn, chỉ ghi thêm, phù hợp với hồ dữ liệu trên S3 chứ không phải CSDL quan hệ. Và DMS dùng để di chuyển CSDL, không phải để nạp log.

Ghi nhớ

Ba dịch vụ bảo mật hay bị lẫn — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Amazon Security Lake | GOM và CHUẨN HOÁ dữ liệu bảo mật vào S3 | | AWS Security Hub | tổng hợp PHÁT HIỆN, chấm điểm tuân thủ | | Amazon GuardDuty | PHÁT HIỆN mối đe doạ bằng học máy | | Amazon Detective | ĐIỀU TRA nguyên nhân gốc |

Từ khoá nhận diện:

"centralize and normalize security data" + "least development" → Security Lake "aggregate findings, compliance score" → Security Hub "detect threats, anomalous behavior" → GuardDuty "investigate an incident, visualize relationships" → Detective

Ba dịch vụ bảo mật khác cần biết: | Dịch vụ | Việc | |---|---| | Amazon Macie | tìm dữ liệu nhạy cảm trong S3 | | Amazon Inspector | quét lỗ hổng EC2, container, Lambda | | AWS Config | đánh giá cấu hình theo quy tắc |

Ba đặc điểm của Security Lake: | Đặc điểm | Chi tiết | |---|---| | Chuẩn OCSF, định dạng Parquet | | | Gom từ nhiều tài khoản và vùng | qua Organizations | | Vòng đời lưu trữ cấu hình được | |

Ba khái niệm cần nắm: | Khái niệm | Nghĩa | |---|---| | Rollup Region | vùng gom dữ liệu từ các vùng khác | | Subscriber | bên được cấp quyền đọc dữ liệu | | Custom source | nguồn log ngoài AWS |

Rollup Region giải quyết yêu cầu đa vùng:

aws securitylake create-data-lake --configurations '[{
  "region":"ap-southeast-1",
  "replicationConfiguration":{
    "regions":["us-east-1","eu-west-1"],
    "roleArn":"<arn-role>"}}]'

Dữ liệu từ mọi vùng gom về một nơi
    → một chỗ để truy vấn
    → thay vì mở từng vùng lên tra

Hai loại subscriber: | Loại | Cách truy cập | |---|---| | Data access | đọc thẳng từ S3, nhận thông báo SQS | | Query access | truy vấn qua Lake Formation và Athena |

aws securitylake create-subscriber   --subscriber-name doi-soc --access-types QUERY_ACCESS   --subscriber-identity '{"principal":"111122223333","externalId":"soc-1"}'   --sources '[{"awsLogSource":{"sourceName":"CLOUD_TRAIL_MGMT","sourceVersion":"2.0"}}]'

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí Security Lake theo GB nạp vào | | | Phí lưu trữ S3 | dùng lifecycle | | Phí truy vấn Athena theo dữ liệu quét | |

Vòng đời là công cụ tiết kiệm chính:

Nóng (Standard)     → 30 ngày, điều tra sự cố gần đây
IA                  → 90 ngày
Glacier             → tuân thủ dài hạn
Xoá                 → sau thời hạn lưu trữ bắt buộc

Ba lưu ý khi truy vấn: | Lưu ý | Chi tiết | |---|---| | Luôn lọc theo eventday | cột phân vùng | | Không quét toàn bộ bảng | | | Đặt workgroup giới hạn dữ liệu quét | |

Vế đầu là khác biệt lớn về chi phí:

Không lọc eventday → quét toàn bộ lịch sử
    → Athena tính tiền theo dữ liệu quét
        ↓
    Một truy vấn viết ẩu có thể tốn hơn cả tháng lưu trữ

Ba lưu ý về triển khai đa tài khoản: | Lưu ý | Chi tiết | |---|---| | Uỷ quyền quản trị cho tài khoản bảo mật | | | Bật tự động cho tài khoản mới | | | Kiểm tra nguồn log đã bật ở mọi vùng | |

aws securitylake register-data-lake-delegated-administrator   --account-id 444455556666

Ba công cụ phân tích trên Security Lake: | Công cụ | Việc | |---|---| | Amazon Athena | truy vấn SQL trực tiếp | | Amazon OpenSearch | tìm kiếm và bảng điều khiển | | SIEM bên thứ ba | Splunk, Datadog qua subscriber |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra dữ liệu đã tới S3 chưa | sau vài giờ | | Chạy một truy vấn Athena mẫu | | | Kiểm tra mọi tài khoản đã tham gia chưa | |

Và một lời khuyên: hãy cấu hình vòng đời lưu trữ ngay khi bật Security Lake. Log bảo mật tích tụ với tốc độ đáng kinh ngạc — VPC Flow Logs của một môi trường vừa phải cũng sinh hàng trăm GB mỗi tháng — và một hồ dữ liệu không có chính sách chuyển tầng sẽ trở thành khoản chi phí lớn thứ hai trong hoá đơn AWS trước khi ai kịp nhận ra.

Câu 917 AWS Storage

A Solutions Architect must design a solution to allow many Amazon EC2 instances across multiple subnets to access a shared data store. The data must be accessed by all instances simultaneously and access should use the NFS protocol. The solution must also be highly scalable and easy to implement.

Which solution best meets these requirements?

  1. A

    Create an Amazon S3 bucket and configure a Network ACL. Grant the EC2 instances permission to access the bucket using the NFS protocol.
  2. B

    Create an Amazon EFS file system. Configure a mount target in each Availability Zone. Attach each instance to the appropriate mount target.
  3. C

    Configure an additional EC2 instance as a file server. Create a role in AWS IAM that grants permissions to the file share and attach the role to the EC2 instances.
  4. D

    Create an Amazon EBS volume and create a resource-based policy that grants an AWS IAM role access to the data. Attach the role to the EC2 instances.
Xem giải thích

Đáp án

B — Tạo Amazon EFS file system, cấu hình một mount target ở mỗi Availability Zone, và gắn mỗi instance vào mount target tương ứng.

Vì sao đúng

Đề nêu bốn yêu cầu, và EFS khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Nhiều EC2 ở NHIỀU SUBNET cùng truy cập | EFS mount đồng thời từ hàng nghìn máy | | Truy cập ĐỒNG THỜI | NFS hỗ trợ nhiều client cùng lúc | | Dùng giao thức NFS | EFS chính là NFS v4 | | Mở rộng tốt, dễ triển khai | tự co giãn, không cấp phát trước |

Vì sao "mount target mỗi AZ" là yêu cầu bắt buộc:

Mount target là một ENI có IP riêng trong subnet
    → instance ở AZ nào phải mount qua target của AZ đó
        ↓
    Thiếu mount target ở một AZ
    → instance ở đó KHÔNG mount được (lệnh treo rồi timeout)

Tạo EFS và mount target:

aws efs create-file-system --performance-mode generalPurpose   --throughput-mode elastic --encrypted --tags Key=Name,Value=kho-chung

aws efs create-mount-target --file-system-id fs-abc   --subnet-id subnet-az-a --security-groups sg-efs
aws efs create-mount-target --file-system-id fs-abc   --subnet-id subnet-az-b --security-groups sg-efs

Mount trên EC2:

sudo yum install -y amazon-efs-utils
sudo mount -t efs -o tls fs-abc:/ /du-lieu-chung

Và trong /etc/fstab để tự mount khi khởi động:

fs-abc:/ /du-lieu-chung efs _netdev,tls 0 0

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tự co giãn tới petabyte | không cấp phát trước | | Trả tiền theo dung lượng THỰC DÙNG | | | Dữ liệu nhân bản qua nhiều AZ | |

Vế thứ hai khác hẳn EBS:

EBS:  cấp 1 TB, dùng 200 GB → trả tiền 1 TB
EFS:  dùng 200 GB → trả tiền 200 GB
        ↓
    Không phải dự đoán trước dung lượng

Và "dễ triển khai" là thật:

Tạo file system → tạo mount target → mount
    → ba bước, không cấu hình máy chủ nào

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

  • **C. Dựng thêm một EC2 làm file server và dùng IAM role cấp quyền — đây là phương án gần nhất vì cũng tạo ra lưu trữ chia sẻ, nhưng nó tạo điểm hỏng đơn lẻ: máy đó chết là cả nhóm mất dữ liệu, và bạn phải tự vá lỗi, tự sao lưu, tự mở rộng. Ngoài ra IAM role không phải cơ chế cấp quyền cho file share NFS.
  • **A. Tạo S3 bucket và cấu hình Network ACL, cấp quyền truy cập bằng giao thức NFS — S3 không hỗ trợ NFS. Nó là object store qua HTTP API, không mount làm hệ thống tệp được (trừ khi qua Storage Gateway hoặc Mountpoint, cả hai đều không phải mô tả trong phương án này).
  • **D. Tạo EBS volume với resource-based policy cấp quyền cho IAM role — EBS không có resource-based policy, và một EBS volume chỉ gắn được vào một instance tại một thời điểm (trừ Multi-Attach, vốn chỉ trong một AZ và chỉ với io1/io2).

Ghi nhớ

Ba loại lưu trữ — bảng phải thuộc: | Loại | Dịch vụ | Nhiều máy dùng chung | |---|---|---| | Khối (block) | EBS, instance store | ❌ | | Tệp (file) | EFS, FSx | ✅ | | Object | S3 | ✅ qua API |

Từ khoá nhận diện — ánh xạ giao thức:

"NFS", "Linux", "POSIX", "concurrent" → EFS "SMB", "Windows", "Active Directory" → FSx for Windows "Lustre", "HPC" → FSx for Lustre "object", "REST API" → S3

Ba đặc điểm của mount target: | Đặc điểm | Chi tiết | |---|---| | Một mount target mỗi AZ | không phải mỗi subnet | | Là một ENI có IP riêng | | | Có security group riêng | |

⚠ Security group của EFS phải mở cổng 2049:

aws ec2 authorize-security-group-ingress --group-id sg-efs   --protocol tcp --port 2049 --source-group sg-ung-dung

Đây là lỗi hay gặp nhất khi mount EFS lần đầu
    → lệnh mount treo rất lâu rồi báo timeout
    → thông báo không hề nhắc tới security group

Hai chế độ hiệu năng: | Chế độ | Đặc điểm | |---|---| | General Purpose | độ trễ thấp nhất — mặc định | | Max I/O | thông lượng cao hơn, độ trễ cao hơn |

⚠ Không đổi được sau khi tạo — phải tạo file system mới và chép dữ liệu.

Ba chế độ thông lượng: | Chế độ | Đặc điểm | |---|---| | Elastic | tự co giãn, trả theo dùng ← khuyến nghị | | Bursting | theo dung lượng, có credit | | Provisioned | cố định |

⚠ Bursting là bẫy với file system nhỏ:

Thông lượng cơ sở = 50 KB/s mỗi GB
    → file system 100 GB → chỉ 5 MB/s cơ sở
    → burst credit cạn → chậm đột ngột
        ↓
    Theo dõi BurstCreditBalance, hoặc dùng Elastic

Bốn lớp lưu trữ EFS: | Lớp | Đặc điểm | |---|---| | Standard | đa AZ, giá cao nhất | | Infrequent Access (IA) | rẻ hơn ~85%, có phí đọc | | Archive | rẻ hơn nữa | | One Zone | một AZ, rẻ hơn nhưng kém sẵn sàng |

Lifecycle tự chuyển tầng:

aws efs put-lifecycle-configuration --file-system-id fs-abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToArchive":"AFTER_90_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

Chính sách cuối đáng có: tệp bị đọc lại tự quay về Standard, tránh trả phí đọc IA nhiều lần.

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bật khi TẠO | không bật sau được | | -o tls cho mã hoá đường truyền | | | Access point giới hạn thư mục và UID/GID | |

Access point rất hữu ích khi nhiều ứng dụng dùng chung:

aws efs create-access-point --file-system-id fs-abc   --posix-user Uid=1001,Gid=1001   --root-directory 'Path=/ung-dung-a,CreationInfo={
    OwnerUid=1001,OwnerGid=1001,Permissions=750}'

Mỗi ứng dụng thấy thư mục riêng như thư mục gốc
    → không đụng được dữ liệu của ứng dụng khác

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Độ trễ cao hơn EBS | NFS qua mạng | | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | Không đặt CSDL cần IOPS cao trên EFS | |

Ba lưu ý khi dùng với Auto Scaling: | Lưu ý | Chi tiết | |---|---| | Đưa lệnh mount vào user data | không chỉ sửa fstab | | Máy mới tự mount được | | | Kiểm tra security group của launch template | |

Vế đầu là chỗ hay gãy nhất:

Chỉ sửa /etc/fstab trên máy đang chạy
    → ASG tạo máy mới → không mount EFS
    → ghi vào đĩa cục bộ → mất khi máy bị thay
        ↓
    Và điều này xảy ra âm thầm

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% là chạm trần General Purpose | | BurstCreditBalance | nếu dùng Bursting | | ClientConnections | số máy đang mount |

Và một lời khuyên: hãy kiểm tra security group cho cổng 2049 trước khi đi tìm nguyên nhân khác khi lệnh mount treo. Đây là lỗi phổ biến nhất với EFS, và triệu chứng của nó — lệnh đứng im rất lâu rồi báo timeout — trông giống hệt lỗi mạng, lỗi DNS, hay lỗi cấu hình file system.

Câu 918 AWS Storage

An application runs on Amazon EC2 Linux instances. The application generates log files which are written using standard API calls. A storage solution is required that can be used to store the files indefinitely and must allow concurrent access to all files.

Which storage service meets these requirements and is the MOST cost-effective?

  1. A

    Amazon EFS
  2. B

    Amazon S3
  3. C

    Amazon EBS
  4. D

    Amazon EC2 instance store
Xem giải thích

Đáp án

B — Amazon S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và S3 thoả cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | **Tệp log ghi bằng API chuẩn | S3 là dịch vụ dùng qua API | | Lưu VÔ THỜI HẠN | S3 không giới hạn dung lượng | | Truy cập ĐỒNG THỜI mọi tệp | nhiều client đọc ghi song song | | TIẾT KIỆM NHẤT | rẻ nhất trong bốn lựa chọn |

Vế đầu là chi tiết dễ bỏ qua nhưng rất quan trọng:

"log files which are written using STANDARD API CALLS"
        ↓
    Ứng dụng gọi API để ghi, không dùng open()/write() của hệ thống tệp
    → đây chính là cách làm việc với S3
        ↓
    Nếu đề nói "native file system interface" thì đáp án sẽ là EFS

Ghi log lên S3:

import boto3, gzip, json
s3 = boto3.client('s3')

s3.put_object(
    Bucket='kho-log-ung-dung',
    Key=f'nam=2026/thang=08/ngay=30/may={ma_may}/{ma_lo}.json.gz',
    Body=gzip.compress(json.dumps(cac_dong_log).encode()))

Vì sao S3 rẻ nhất trong bốn lựa chọn: | Dịch vụ | Giá tương đối mỗi GB-tháng | |---|---| | S3 Standard | 1× | | EBS gp3 | ~3,5× | | EFS Standard | ~13× | | Instance store | (gộp trong giá instance, mất dữ liệu) |

Và lifecycle làm nó còn rẻ hơn nữa:

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

Log cũ hầu như không ai đọc
    → Deep Archive rẻ hơn Standard khoảng 25 lần
        ↓
    "Lưu vô thời hạn" trở nên khả thi về chi phí

Ba lợi ích khác: | Lợi ích | Chi tiết | |---|---| | 11 số 9 độ bền | | | Truy vấn trực tiếp bằng Athena | không cần nạp đi đâu | | Không có gì để vận hành | |

Vế thứ hai đáng khai thác:

CREATE EXTERNAL TABLE log_ung_dung (...)
PARTITIONED BY (nam string, thang string, ngay string)
STORED AS PARQUET LOCATION 's3://kho-log-ung-dung/';

SELECT muc_do, count(*) FROM log_ung_dung
WHERE nam='2026' AND thang='08' GROUP BY muc_do;

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

  • **A. Amazon EFS — đây là phương án gần nhất vì cũng cho truy cập đồng thời và lưu vô thời hạn, nhưng nó đắt hơn S3 khoảng một bậc. Và EFS là hệ thống tệp POSIX, trong khi đề nói ứng dụng ghi bằng lời gọi API, tức là không cần giao diện hệ thống tệp.
  • **C. Amazon EBS — không hỗ trợ truy cập đồng thời: một volume gắn vào một instance tại một thời điểm. Và phải cấp phát dung lượng trước, nên "lưu vô thời hạn" nghĩa là liên tục mở rộng volume bằng tay.
  • **D. Instance store — dữ liệu MẤT khi instance dừng hoặc bị chấm dứt. Hoàn toàn mâu thuẫn với yêu cầu lưu vô thời hạn.

Ghi nhớ

Bốn lựa chọn lưu trữ EC2 — bảng phải thuộc: | Lựa chọn | Chia sẻ | Bền vững | Giá | |---|---|---|---| | Amazon S3 | ✅ qua API | ✅ 11 số 9 | rẻ nhất | | Amazon EFS | ✅ NFS | ✅ | đắt hơn ~13× | | Amazon EBS | ❌ | ✅ | ~3,5× | | Instance store | ❌ | ❌ mất khi stop | (gộp giá máy) |

Từ khoá nhận diện:

"standard API calls" + "indefinitely" + "most cost-effective" → S3 "native file system interface", "POSIX" → EFS "single instance, block storage" → EBS "temporary, highest IOPS" → instance store

Ba cách đưa log lên S3: | Cách | Đặc điểm | |---|---| | Ứng dụng gọi SDK trực tiếp | ← câu này | | CloudWatch Logs rồi export sang S3 | có tìm kiếm thời gian thực | | Kinesis Data Firehose | đệm và gộp lô tự động |

Firehose đáng cân nhắc cho khối lượng lớn:

Ứng dụng gửi từng dòng log → Firehose
    → đệm 5 phút hoặc 5 MB
    → ghi thành tệp lớn vào S3, nén sẵn
        ↓
    Ít request hơn, tệp lớn hơn, rẻ hơn

⚠ Ba lỗi thiết kế khi ghi log lên S3: | Lỗi | Hậu quả | |---|---| | Mỗi dòng log một object | phí PUT request rất lớn | | Không nén | tốn dung lượng gấp 5-10 lần | | Không phân vùng theo ngày | truy vấn quét toàn bộ |

Dòng đầu là sai lầm tốn kém nhất:

1 triệu dòng log mỗi ngày, mỗi dòng một object
    → 1 triệu PUT request mỗi ngày
    → phí request vượt xa phí lưu trữ
        ↓
    Gộp thành tệp theo lô: 1 triệu dòng → vài trăm object

Ba lưu ý về phân vùng: | Lưu ý | Chi tiết | |---|---| | Đặt khoá dạng nam=/thang=/ngay= | Athena tự nhận partition | | Thêm chiều máy chủ hoặc dịch vụ nếu cần | | | Đừng phân vùng quá nhỏ | quá nhiều partition cũng chậm |

Ba định dạng lưu log: | Định dạng | Đặc điểm | |---|---| | JSON nén gzip | đơn giản, dễ đọc | | Parquet | cột, truy vấn rẻ hơn nhiều | | Text thuần | tệ nhất về chi phí |

Parquet giảm chi phí truy vấn rất mạnh:

Athena tính tiền theo dữ liệu QUÉT
    → JSON: quét toàn bộ dòng
    → Parquet: chỉ đọc cột cần
        ↓
    Cùng một câu hỏi có thể chênh nhau 10-100 lần chi phí

Ba lớp lưu trữ cho log theo tuổi: | Tuổi | Lớp | |---|---| | 0-30 ngày | Standard (hay đọc để gỡ lỗi) | | 30-90 ngày | Standard-IA hoặc Glacier IR | | > 1 năm | Deep Archive |

⚠ Nhớ giới hạn 128 KB của lớp IA:

Object nhỏ hơn 128 KB bị tính phí như 128 KB
    → gộp log thành tệp lớn trước
        ↓
    Đây là thêm một lý do không ghi mỗi dòng một object

Ba lưu ý về bảo mật log: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá (SSE-S3 mặc định, hoặc SSE-KMS) | | | Bật versioning và Object Lock nếu cần tuân thủ | | | Chặn public access | |

Object Lock cho log cần bất biến:

aws s3api put-object-lock-configuration --bucket kho-log-ung-dung   --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":2555}}}'

Chế độ COMPLIANCE: không ai xoá được trước hạn
    → kể cả tài khoản root
        ↓
    Cân nhắc rất kỹ — không gỡ được

Ba quy tắc lifecycle nên có: | Quy tắc | Việc | |---|---| | Transitions theo tuổi | giảm chi phí | | AbortIncompleteMultipartUpload | dọn phần tải lên dở | | NoncurrentVersionExpiration | nếu bật versioning |

Ba công cụ phân tích log trong S3: | Công cụ | Việc | |---|---| | Amazon Athena | SQL trực tiếp | | Amazon OpenSearch | tìm kiếm và bảng điều khiển | | AWS Glue | ETL và danh mục |

Ba metric nên theo dõi: | Metric | Ý nghĩa | |---|---| | BucketSizeBytes | tăng nhanh không | | NumberOfObjects | có ghi quá vụn không | | Chi phí theo lớp lưu trữ | |

Và một lời khuyên: hãy gộp log thành tệp lớn và nén trước khi ghi lên S3, ngay từ ngày đầu. Chi phí lưu trữ của S3 rất thấp, nên khoản làm hoá đơn tăng bất ngờ gần như luôn là phí request — và sửa cách ghi sau khi đã có hàng trăm triệu object nhỏ là công việc dọn dẹp tốn kém hơn nhiều so với làm đúng từ đầu.

Câu 919 AWS Networking & Content Delivery

A company is deploying a solution for sharing media files around the world using Amazon CloudFront with an Amazon S3 origin configured as a static website. The company requires that all traffic for the website must be inspected by AWS WAF.

Which solution meets these requirements?

  1. A

    Use an Amazon Route 53 Alias record to forward traffic for the website to AWS WAF. Configure AWS WAF to inspect traffic and attach the CloudFront distribution.
  2. B

    Deploy CloudFront with an S3 origin and configure an origin access identity (OAI) to restrict access to the S3 bucket. Enable AWS WAF on the CloudFront distribution.
  3. C

    Create an S3 bucket policy with a condition that only allows requests that originate from AWS WAF.
  4. D

    Create a Network ACL that limits access to the S3 bucket to the CloudFront IP addresses. Attach a WebACL to the CloudFront distribution.
Xem giải thích

Đáp án

B — Triển khai CloudFront với S3 làm origin, cấu hình origin access identity (OAI) để giới hạn truy cập vào bucket, và bật AWS WAF trên CloudFront distribution.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này thoả cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Phân phối media toàn cầu qua CloudFront + S3 | kiến trúc chuẩn | | MỌI lưu lượng phải qua AWS WAF kiểm tra | gắn WAF vào CloudFront + chặn đường vào thẳng S3 |

Vế thứ hai gồm hai nửa, và phải làm cả hai:

Nửa 1: gắn WAF web ACL vào CloudFront distribution
    → mọi request qua CloudFront đều bị kiểm tra

Nửa 2: giới hạn bucket chỉ cho CloudFront truy cập
    → không ai vào thẳng S3, bỏ qua WAF
        ↓
    Thiếu nửa 2 thì WAF vô nghĩa:
    kẻ tấn công chỉ cần gọi thẳng URL của S3

Vì sao WAF phải gắn vào CloudFront chứ không phải S3:

AWS WAF gắn được vào:
    → CloudFront distribution
    → Application Load Balancer
    → API Gateway, AppSync, Cognito user pool,
      App Runner, Verified Access
        ↓
    KHÔNG gắn trực tiếp vào S3 bucket được
    → nên phải đặt CloudFront phía trước

Gắn WAF:

aws wafv2 create-web-acl --name bao-ve-media --scope CLOUDFRONT   --region us-east-1   --default-action Allow={}   --rules '[{"Name":"ChanIPXau","Priority":0,
    "Statement":{"ManagedRuleGroupStatement":{
      "VendorName":"AWS","Name":"AWSManagedRulesAmazonIpReputationList"}},
    "OverrideAction":{"None":{}},
    "VisibilityConfig":{"SampledRequestsEnabled":true,
      "CloudWatchMetricsEnabled":true,"MetricName":"ChanIPXau"}}]'   --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=baoVeMedia

aws cloudfront update-distribution --id E123ABC   --distribution-config file://cau-hinh-co-webacl.json

⚠ Web ACL cho CloudFront phải tạo ở us-east-1 với --scope CLOUDFRONT.

Bucket policy chỉ cho CloudFront:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "cloudfront.amazonaws.com"},
   "Action": "s3:GetObject",
   "Resource": "arn:aws:s3:::kho-media/*",
   "Condition": {"StringEquals":
     {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC"}}}]}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mọi request đều qua WAF | không có đường vòng | | Bucket riêng tư hoàn toàn | | | CloudFront cache giảm tải và chi phí | |

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

  • **D. Tạo Network ACL giới hạn truy cập bucket theo dải IP của CloudFront, gắn WebACL vào distribution — sai ở nửa đầu: NACL hoạt động ở tầng subnet trong VPC, còn S3 là dịch vụ vùng không nằm trong VPC nào. Không có NACL nào áp cho bucket được. (Lọc theo dải IP của CloudFront thì phải làm bằng bucket policy với aws:SourceIp và prefix list — nhưng OAC/OAI là cách đúng.)
  • **A. Dùng Route 53 alias record chuyển lưu lượng tới AWS WAF — WAF không phải một endpoint mạng: nó là lớp lọc gắn vào tài nguyên khác, không có địa chỉ để trỏ DNS tới. Câu này mô tả một kiến trúc không tồn tại.
  • **C. Tạo bucket policy chỉ cho phép request đến từ AWS WAF — không có principal hay điều kiện nào biểu diễn được "request came from WAF". WAF không phải nguồn của request; nó chỉ kiểm tra request trên đường đi.

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

Đáp án chọn OAI, và điều đó đúng theo tài liệu tại thời điểm câu hỏi được viết — nhưng cần biết:

AWS đã thay OAI bằng OAC (Origin Access Control) từ tháng 8/2022, và khuyến nghị dùng OAC cho mọi cấu hình mới. OAI vẫn hoạt động với cấu hình cũ, nhưng nó không hỗ trợ một số trường hợp: | Trường hợp | OAI | OAC | |---|---|---| | Bucket mã hoá bằng SSE-KMS | ❌ | ✅ | | Các vùng ra mắt sau 2022 | ❌ | ✅ | | Tải lên (PUT) qua CloudFront | ❌ | ✅ | | Ký động theo từng request | ❌ | ✅ |

Trong kỳ thi, "OAI" vẫn là lựa chọn được chấp nhận khi nó là phương án duy nhất mô tả đúng ý tưởng "giới hạn bucket chỉ cho CloudFront". Nhưng khi dựng hệ thống thật, hãy dùng OAC:

aws cloudfront create-origin-access-control   --origin-access-control-config   'Name=oac-media,OriginAccessControlOriginType=s3,
   SigningBehavior=always,SigningProtocol=sigv4'

Ghi nhớ

Ba lớp bảo vệ của AWS — bảng phải thuộc: | Dịch vụ | Bảo vệ khỏi | Tầng | |---|---|---| | AWS WAF | SQLi, XSS, bot, tần suất | tầng 7 (HTTP) | | AWS Shield Standard | DDoS tầng 3/4 | miễn phí, tự động | | AWS Shield Advanced | DDoS lớn, có đội hỗ trợ | trả phí |

Từ khoá nhận diện:

"inspect all traffic to a website" → WAF trên CloudFront hoặc ALB "restrict S3 to CloudFront only" → OAC (hoặc OAI ở đề cũ) "DDoS protection with cost protection" → Shield Advanced

Sáu tài nguyên gắn được WAF: | Tài nguyên | Scope | |---|---| | CloudFront | CLOUDFRONT (us-east-1) | | Application Load Balancer | REGIONAL | | API Gateway | REGIONAL | | AppSync, Cognito user pool | REGIONAL | | App Runner, Verified Access | REGIONAL |

⚠ S3 KHÔNG có trong danh sách — đó là lý do phải đặt CloudFront phía trước.

Ba loại rule của WAF: | Loại | Việc | |---|---| | Managed rule group của AWS | OWASP Top 10, IP xấu, bot | | Rate-based rule | chặn IP vượt ngưỡng request | | Custom rule | theo IP, địa lý, header, thân request |

Rate-based rule chống lạm dụng băng thông:

{"Name":"GioiHanTanSuat","Priority":1,
 "Statement":{"RateBasedStatement":{"Limit":2000,"AggregateKeyType":"IP"}},
 "Action":{"Block":{}},
 "VisibilityConfig":{"SampledRequestsEnabled":true,
   "CloudWatchMetricsEnabled":true,"MetricName":"GioiHanTanSuat"}}

Với site chia sẻ media, đây là luật quan trọng nhất
    → một script tải hàng loạt có thể đội chi phí truyền dữ liệu

Ba managed rule group nên bật: | Nhóm | Bảo vệ | |---|---| | AWSManagedRulesCommonRuleSet | XSS, path traversal | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesKnownBadInputsRuleSet | payload tấn công đã biết |

Ba lưu ý khi bật WAF lần đầu: | Lưu ý | Chi tiết | |---|---| | Bật ở chế độ COUNT trước | xem có chặn nhầm không | | Đọc sampled request | | | Rồi mới chuyển sang BLOCK | |

Vế đầu tránh được sự cố:

Bật BLOCK ngay với managed rule
    → có thể chặn nhầm request hợp lệ
    → người dùng thật nhận 403
        ↓
    Chế độ COUNT ghi lại mà không chặn

Ba lưu ý về CloudFront + S3: | Lưu ý | Chi tiết | |---|---| | Dùng REST endpoint của S3, không dùng website endpoint | | | Bật Block Public Access trên bucket | | | ViewerProtocolPolicy: redirect-to-https | |

⚠ Website endpoint không dùng được với OAC/OAI:

S3 website endpoint (s3-website-...) yêu cầu bucket CÔNG KHAI
    → không giới hạn cho riêng CloudFront được
        ↓
    Phải dùng REST endpoint (s3.amazonaws.com)

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | WAF tính theo web ACL, rule, và số request | | | CloudFront: S3 → CloudFront miễn phí | | | Cache tốt giảm cả hai | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử gọi thẳng URL S3 | phải bị từ chối | | Kiểm tra WAF log có ghi request | | | Thử một request độc hại | phải bị chặn |

Và một lời khuyên: hãy thử gọi thẳng URL của S3 sau khi cấu hình xong. Đó là bài kiểm tra duy nhất chứng minh WAF thực sự nằm trên mọi đường đi — một web ACL gắn hoàn hảo vào CloudFront vẫn vô dụng nếu bucket còn một đường vào mà không ai nhớ đã mở.

Câu 920 AWS Networking & Content Delivery

A company hosts statistical data in an Amazon S3 bucket that users around the world download from their website using a URL that resolves to a domain name. The company needs to provide low latency access to users and plans to use Amazon Route 53 for hosting DNS records.

Which solution meets these requirements?

  1. A

    Create a web distribution on Amazon CloudFront pointing to an Amazon S3 origin. Create an ALIAS record in the Amazon Route 53 hosted zone that points to the CloudFront distribution, resolving to the application's URL domain name.
  2. B

    Create a web distribution on Amazon CloudFront pointing to an Amazon S3 origin. Create a CNAME record in a Route 53 hosted zone that points to the CloudFront distribution, resolving to the application's URL domain name.
  3. C

    Create an A record in Route 53, use a Route 53 traffic policy for the web application, and configure a geoproximity rule. Configure health checks to check the health of the endpoint and route DNS queries to other endpoints if an endpoint is unhealthy.
  4. D

    Create an A record in Route 53, use a Route 53 traffic policy for the web application, and configure a geolocation rule. Configure health checks to check the health of the endpoint and route DNS queries to other endpoints if an endpoint is unhealthy.
Xem giải thích

Đáp án

A — Tạo CloudFront distribution trỏ tới S3 làm origin, và tạo một bản ghi ALIAS trong hosted zone của Route 53 trỏ tới distribution đó.

Vì sao đúng

Đề nêu ba dữ kiện, và phương án này khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Dữ liệu tĩnh trong S3, người dùng toàn cầu tải về | CloudFront cache ở edge gần người dùng | | Cần ĐỘ TRỄ THẤP | nội dung phục vụ từ edge, không đi tới vùng gốc | | Dùng Route 53 làm DNS | ALIAS record trỏ tới distribution |

Vì sao ALIAS chứ không phải CNAME — đây là điểm phân biệt A và B:

CNAME:
    → KHÔNG dùng được ở ĐỈNH TÊN MIỀN (zone apex)
      tức là vidu.com — chỉ dùng được cho www.vidu.com
    → tính phí cho mỗi truy vấn DNS
    → thêm một vòng phân giải

ALIAS (bản ghi riêng của Route 53):
    → dùng được ở CẢ zone apex
    → MIỄN PHÍ khi trỏ tới tài nguyên AWS
    → phân giải thẳng thành IP, không thêm vòng

Tạo ALIAS record:

aws route53 change-resource-record-sets --hosted-zone-id Z123ABC   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"du-lieu.vidu.com","Type":"A",
    "AliasTarget":{"HostedZoneId":"Z2FDTNDATAQYW2",
      "DNSName":"d111111abcdef8.cloudfront.net",
      "EvaluateTargetHealth":false}}}]}'

⚠ Z2FDTNDATAQYW2 là hosted zone ID cố định của CloudFront — luôn dùng giá trị này cho mọi distribution.

Ba lợi ích của CloudFront ở đây: | Lợi ích | Chi tiết | |---|---| | Cache ở hơn 600 edge location | độ trễ thấp toàn cầu | | Data transfer S3 → CloudFront MIỄN PHÍ | thường rẻ hơn phục vụ thẳng từ S3 | | HTTPS miễn phí qua ACM | |

Và bảo vệ bucket bằng OAC:

aws cloudfront create-origin-access-control   --origin-access-control-config   'Name=oac-du-lieu,OriginAccessControlOriginType=s3,
   SigningBehavior=always,SigningProtocol=sigv4'

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

  • **B. CloudFront + CNAME record trong Route 53 — đây là phương án gần nhất và về mặt kỹ thuật vẫn phân giải được, nhưng nó kém hơn ALIAS ở ba điểm: không dùng được ở đỉnh tên miền, tính phí mỗi truy vấn DNS, và thêm một vòng phân giải. Với tài nguyên AWS thì ALIAS luôn là lựa chọn đúng.
  • **C. Bản ghi A với traffic policy geoproximity và health check — sai công cụ cho vấn đề: geoproximity định tuyến tới endpoint gần nhất về địa lý, nhưng ở đây chỉ có một bucket S3. Không có nhiều endpoint để chọn, và định tuyến DNS không cache nội dung nên không giảm được độ trễ tải xuống.
  • **D. Bản ghi A với geolocation rule — cùng vấn đề, và geolocation còn cứng nhắc hơn: nó định tuyến theo quốc gia của người dùng chứ không theo hiệu năng, thường dùng cho bản quyền nội dung.

Ghi nhớ

⚠ ALIAS và CNAME — bảng phải thuộc: | | ALIAS | CNAME | |---|---|---| | Dùng ở zone apex (vidu.com) | ✅ | ❌ | | Phí truy vấn | miễn phí (tới tài nguyên AWS) | tính phí | | Trỏ tới | tài nguyên AWS | bất kỳ tên miền nào | | Loại bản ghi | A hoặc AAAA | CNAME | | Health check target | EvaluateTargetHealth | không |

Từ khoá nhận diện:

"Route 53 + AWS resource (CloudFront, ALB, S3 website)" → ALIAS "point to an external domain" → CNAME "low latency for global users downloading content" → CloudFront

Sáu tài nguyên ALIAS trỏ tới được: | Tài nguyên | Ghi chú | |---|---| | CloudFront distribution | ← câu này | | Application / Network Load Balancer | | | S3 static website endpoint | | | API Gateway | | | VPC interface endpoint | | | Bản ghi khác trong cùng hosted zone | |

Bảy chính sách định tuyến của Route 53 — bảng phải thuộc: | Chính sách | Chọn theo | |---|---| | Simple | một đích duy nhất | | Weighted | tỷ lệ phần trăm | | Latency-based | độ trễ mạng ĐO ĐƯỢC | | Failover | chính/phụ theo health check | | Geolocation | quốc gia của người dùng | | Geoproximity | khoảng cách địa lý, có bias | | Multivalue answer | tới 8 bản ghi khoẻ mạnh |

⚠ Ba chính sách dễ lẫn nhất:

Latency-based:  "vùng nào TRẢ LỜI NHANH NHẤT"  → hiệu năng
Geolocation:    "người dùng Ở ĐÂU"             → tuân thủ, bản quyền
Geoproximity:   "khoảng cách địa lý + bias"    → điều chỉnh tỷ lệ theo vùng

Ba lưu ý khi dùng CloudFront với S3: | Lưu ý | Chi tiết | |---|---| | Dùng REST endpoint, không dùng website endpoint | để dùng được OAC | | Chứng chỉ ACM phải ở us-east-1 | | | Bật Block Public Access trên bucket | |

Ba cách tối ưu chi phí: | Cách | Chi tiết | |---|---| | Chọn price class hợp phân bố khách | | | Bật nén (gzip, Brotli) | | | TTL dài cho dữ liệu tĩnh | |

Ba lỗi làm hỏng tỷ lệ cache hit: | Lỗi | Hậu quả | |---|---| | Forward mọi cookie | mỗi khách một bản cache | | Forward mọi query string | ?utm_source= tách cache | | TTL quá ngắn | |

Ba lưu ý về health check của Route 53: | Lưu ý | Chi tiết | |---|---| | RequestInterval 30 giây (hoặc 10 giây fast) | | | FailureThreshold số lần hỏng liên tiếp | | | TTL ngắn để client không giữ IP cũ | |

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | ALIAS kế thừa TTL của tài nguyên đích | | | TTL dài giảm phí truy vấn | | | TTL ngắn cho bản ghi failover | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig du-lieu.vidu.com | ra IP của CloudFront | | Kiểm tra header X-Cache | Hit hay Miss | | Đo độ trễ từ nhiều khu vực | |

curl -sI https://du-lieu.vidu.com/bao-cao.csv | grep -i x-cache

Và một lời khuyên: hãy dùng ALIAS làm mặc định cho mọi bản ghi trỏ tới tài nguyên AWS. Nó miễn phí, nhanh hơn một vòng phân giải, và dùng được ở đỉnh tên miền — nghĩa là bạn không bao giờ phải phát hiện ra giới hạn của CNAME vào đúng lúc muốn trỏ vidu.com thay vì www.vidu.com.