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

Đáp án

D — Dùng IAM role và resource-based policy để uỷ quyền chéo tài khoản giữa các partition khác nhau, chỉ qua truy cập lập trình — đây là phương án KHÔNG khả thi.

Vì sao đúng

Câu hỏi tìm phương án không làm được, và điểm mấu chốt nằm ở từ "partition".

AWS partition là ranh giới cô lập cao nhất — cao hơn cả Region:

Bạn nhìn thấy partition ngay trong mọi ARN:

arn:aws:s3:::bucket-thuong-mai
arn:aws-cn:s3:::bucket-trung-quoc
arn:aws-us-gov:s3:::bucket-govcloud

Các partition hoàn toàn cô lập với nhau: IAM riêng, tài khoản riêng, endpoint riêng. Không có cách nào để một IAM principal ở partition aws assume role hay truy cập tài nguyên ở partition aws-cn — không phải vì thiếu cấu hình, mà vì cơ chế không tồn tại.

Muốn chuyển dữ liệu giữa hai partition thì phải làm ở tầng ứng dụng: một bên đọc ra, một bên ghi vào, với hai bộ thông tin xác thực riêng biệt.

Vì sao các phương án khác khả thi

• A. Resource-based policy + IAM policy, truy cập lập trình — mẫu chuẩn: bucket policy ở tài khoản Finance cho phép principal của HR, cộng identity policy phía HR.
• B. ACL + IAM policy, truy cập lập trình — làm được, dù ACL là cơ chế cũ mà AWS khuyến nghị không dùng nữa (nên bật Bucket owner enforced để tắt hẳn ACL).
• C. Cross-account IAM role, truy cập lập trình và console — cách được khuyến nghị nhất. Role cho phép switch role trong Console, thứ mà bucket policy đơn thuần không làm được.

Ghi nhớ

Ba cách chia sẻ S3 chéo tài khoản, và khác biệt của chúng: | Cách | Console | Lập trình | Ghi chú | |---|---|---|---| | Cross-account IAM role | ✅ | ✅ | linh hoạt nhất, có vết CloudTrail hai phía | | Bucket policy | ❌ | ✅ | đơn giản, không cần assume role | | ACL | ❌ | ✅ | cũ — nên tránh |

Và nhớ thứ tự cô lập từ rộng tới hẹp: partition → Region → Availability Zone. Partition là ranh giới không vượt qua được; Region thì vượt được với một số dịch vụ (S3 CRR, DynamoDB global tables, VPC peering).

Đáp án

B và D.

• B — Dùng ElastiCache để cải thiện độ trễ và thông lượng cho workload đọc nhiều.
• D — Dùng ElastiCache để cải thiện hiệu năng cho workload nặng về tính toán.

Vì sao đúng

ElastiCache là cache trong bộ nhớ, và nó phát huy tác dụng khi cùng một kết quả được dùng lại nhiều lần.

B — workload đọc nhiều. Đây là trường hợp dùng kinh điển. Thay vì mỗi lần đều truy vấn CSDL, kết quả được cache lại:

Không cache: 10.000 request/giây → 10.000 truy vấn CSDL
Có cache   : 10.000 request/giây →    vài chục truy vấn CSDL

Độ trễ giảm từ hàng chục mili giây (CSDL) xuống dưới một mili giây (bộ nhớ).

D — workload nặng tính toán. Nguyên tắc giống hệt, chỉ khác thứ được cache: thay vì cache kết quả truy vấn, bạn cache kết quả của một phép tính tốn kém. Ví dụ: bảng xếp hạng phải tổng hợp từ hàng triệu bản ghi, hay kết quả suy luận của một mô hình. Tính một lần, phục vụ hàng nghìn lần.

Đây là trường hợp dùng được AWS nêu tên tường minh trong tài liệu ElastiCache.

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

• A. Workload ghi nhiều — cache không giúp gì cho việc ghi. Mỗi lần ghi vẫn phải xuống CSDL, và còn thêm việc: phải vô hiệu hoá hoặc cập nhật entry trong cache. Với tải ghi nặng, cache làm hệ thống phức tạp hơn mà chậm hơn.
• E. Chạy truy vấn JOIN phức tạp — Redis và Memcached không phải CSDL quan hệ; chúng không có JOIN. Bạn có thể cache kết quả của một JOIN đã chạy ở CSDL, nhưng bản thân ElastiCache không thực hiện được JOIN.
• C. Workload ETL — ETL là xử lý theo lô: đọc khối lượng lớn, biến đổi, ghi ra đích. Mỗi bản ghi thường chỉ đọc một lần, nên không có gì để tái sử dụng — cache vô dụng. Công cụ đúng cho ETL là AWS Glue, EMR, hoặc Batch.

Ghi nhớ

Và nhớ phân biệt hai engine: Memcached đơn giản, đa luồng, không bền vững; Redis có sao chép, failover, snapshot và cấu trúc dữ liệu phong phú. Cần dữ liệu không được mất thì đi thêm một bậc nữa: MemoryDB for Redis.

Đáp án

C — Hàm Lambda không có quyền IAM để ghi vào DynamoDB.

Vì sao đúng

Manh mối trong đề khoanh vùng rất chặt: hàm được kích hoạt thành công từ S3 event, nhưng thất bại khi ghi vào DynamoDB.

Vế thứ nhất cho biết trigger và resource-based policy đều đúng. Vế thứ hai chỉ thẳng vào execution role — thứ quyết định hàm làm được gì sau khi đã chạy.

Đây là chỗ cần phân biệt hai loại policy của Lambda, và câu hỏi này được thiết kế đúng quanh nó:

Đề mô tả đúng triệu chứng thứ hai. Policy cần thêm:

{
  "Effect": "Allow",
  "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
  "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/du-lieu"
}

Nơi tìm bằng chứng: CloudWatch Logs của hàm sẽ có dòng AccessDeniedException: User ... is not authorized to perform: dynamodb:PutItem.

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

• A. Vượt giới hạn provisioned concurrency và B. Vượt reserved concurrency — cả hai gây throttling, và triệu chứng là hàm KHÔNG được gọi (lỗi TooManyRequestsException, mã 429). Nhưng đề nói rõ hàm đã được kích hoạt thành công.
• D. "DynamoDB thiếu Gateway VPC Endpoint" — chỉ liên quan khi hàm chạy trong VPC. Đề không nói vậy, và mặc định Lambda KHÔNG nằm trong VPC — nó truy cập dịch vụ AWS qua đường công khai bình thường. (Nếu hàm ở trong VPC thật và thiếu endpoint thì triệu chứng lại là timeout, không phải lỗi ghi.)

Ghi nhớ

Chẩn đoán lỗi Lambda theo triệu chứng: | Triệu chứng | Nghi ngờ đầu tiên | |---|---| | Không được gọi | resource-based policy, cấu hình trigger, throttling | | Chạy rồi lỗi AccessDenied | execution role thiếu quyền | | Timeout | hàm trong VPC thiếu NAT/endpoint, hoặc downstream chậm | | Lỗi Task timed out | timeout quá ngắn | | Runtime exited | hết bộ nhớ |

Và luôn nhớ: CloudWatch Logs của hàm là nơi đầu tiên phải xem. Gần như mọi lỗi lúc chạy đều để lại thông báo cụ thể ở đó.

Đáp án

A — Đưa phần khởi tạo client S3 ra ngoài function handler.

Vì sao đúng

Lambda có một cơ chế tối ưu quan trọng: tái sử dụng execution context. Sau khi một hàm chạy xong, Lambda giữ lại môi trường thực thi một thời gian để phục vụ lời gọi tiếp theo — và mọi thứ khai ngoài handler vẫn còn nguyên.

import boto3

s3 = boto3.client('s3')          # ← NGOÀI handler: chạy MỘT LẦN mỗi môi trường

def handler(event, context):
    s3.put_object(Bucket='log', Key=event['key'], Body=event['data'])   # tái sử dụng

So với cách viết kém hiệu quả:

def handler(event, context):
    s3 = boto3.client('s3')      # ← TRONG handler: chạy lại MỖI LẦN gọi
    s3.put_object(...)

Khởi tạo một AWS SDK client không hề rẻ: nó nạp cấu hình, phân giải Region, lấy thông tin xác thực từ metadata service, và dựng connection pool. Làm lại việc đó ở mỗi lời gọi có thể tốn hàng chục tới hàng trăm mili giây — với hàm được gọi hàng triệu lần thì đó là khoản lãng phí lớn.

Cùng nguyên tắc áp dụng cho: kết nối CSDL, nạp tệp cấu hình, giá trị lấy từ Parameter Store hoặc Secrets Manager (nhớ kèm TTL), và biên dịch biểu thức chính quy.

Một cảnh báo đi kèm: vì context được tái sử dụng, biến toàn cục giữ lại giá trị giữa các lần gọi. Đừng dùng chúng để lưu dữ liệu của một request cụ thể — sẽ rò rỉ sang request khác.

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

• B. Cấp thêm RAM — có làm hàm chạy nhanh hơn (vì CPU tỷ lệ theo bộ nhớ), nhưng đó là biện pháp khác hẳn và không liên quan tới việc tái sử dụng execution context mà trưởng nhóm đề xuất.
• C. Dùng biến môi trường để truyền tham số — thực hành tốt về mặt cấu hình, nhưng không ảnh hưởng gì tới hiệu năng hay việc tái sử dụng context.
• D. Bật tích hợp X-Ray — công cụ quan sát: giúp bạn nhìn thấy hàm chậm ở đâu. Nó không làm hàm nhanh hơn, và thực tế còn thêm một chút chi phí.

Ghi nhớ

Cấu trúc một hàm Lambda được tối ưu:

# ── Vùng INIT: chạy một lần mỗi execution context ──
import boto3, os
s3 = boto3.client('s3')
CAU_HINH = tai_cau_hinh()

def handler(event, context):
    # ── Vùng INVOKE: chạy mỗi lời gọi ──
    return xu_ly(event, s3, CAU_HINH)

Ba việc nên đặt trong vùng INIT: khởi tạo SDK client, mở kết nối CSDL, nạp cấu hình và bí mật. Và nhớ: đừng lưu trạng thái của một request trong biến toàn cục.

Đáp án

D — Tạo cron event trong CloudWatch (EventBridge) kích hoạt một Lambda function để chụp snapshot thủ công của CSDL.

Vì sao đúng

Điểm mấu chốt: automated backup của RDS có giới hạn thời gian giữ tối đa 35 ngày. Hợp đồng đòi giữ backup suốt ba năm — vượt xa giới hạn đó.

Cách chữa là chuyển sang manual snapshot, vì chúng có đặc tính hoàn toàn khác:

Lambda chạy theo lịch hằng tháng:

def handler(event, context):
    rds.create_db_snapshot(
        DBInstanceIdentifier='csdl-benh-vien',
        DBSnapshotIdentifier=f"backup-thang-{datetime.now():%Y-%m}",
        Tags=[{'Key': 'GiuDenNam', 'Value': '2029'}])

EventBridge rule: cron(0 2 1 * ? *)     # 2 giờ sáng ngày 1 hằng tháng

Đặc tính "snapshot tồn tại độc lập với DB instance" rất quan trọng cho tuân thủ: kể cả khi CSDL bị xoá sau ba năm, các snapshot vẫn còn nguyên.

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

• A. Bật automated backup của RDS — đây chính là thứ đã có và không đủ; đề nói rõ giới hạn hiện tại không đáp ứng yêu cầu.
• B. Bật read replica — công cụ mở rộng đọc, không phải cơ chế sao lưu. Replica phản ánh trạng thái hiện tại, không giữ lịch sử — dữ liệu bị xoá nhầm ở primary sẽ bị xoá luôn ở replica.
• C. Bật Multi-AZ — cơ chế tính sẵn sàng cao: standby đồng bộ ở AZ khác, failover tự động. Nó cũng không giữ lịch sử — mọi thay đổi được sao chép ngay lập tức, kể cả thay đổi sai.

Ghi nhớ

Ba khái niệm hay bị lẫn ở tầng CSDL: | | Mục đích | |---|---| | Backup / snapshot | khôi phục dữ liệu về quá khứ | | Multi-AZ | tính sẵn sàng cao — chống hỏng AZ | | Read replica | mở rộng đọc |

Ba thứ này không thay thế được cho nhau, và một hệ thống production thường cần cả ba.

Giải pháp gọn hơn cho cùng bài toán ngày nay: AWS Backup — dịch vụ sao lưu tập trung có backup plan với chính sách giữ tuỳ ý (nhiều năm), backup vault lock để chống xoá (rất quan trọng cho tuân thủ), và sao chép chéo Region. Nó bỏ được toàn bộ phần Lambda tự viết.

Đáp án

B và D.

• D — Bật automated backup của RDS trong triển khai Multi-AZ, tạo backup trong một Region.
• B — Dùng cross-Region read replica.

Vì sao đúng

Hai biện pháp phục vụ hai kịch bản thảm hoạ khác nhau, và đó là lý do cần cả hai.

D — automated backup: chống mất dữ liệu. Backup tự động cho point-in-time recovery, khôi phục được về bất kỳ thời điểm nào trong khoảng giữ (tối đa 35 ngày), độ chính xác tới giây. Đây là biện pháp duy nhất chống được xoá nhầm dữ liệu hoặc hỏng dữ liệu do lỗi ứng dụng — những thứ mà replica sẽ sao chép y nguyên.

Chi tiết đáng chú ý: trong triển khai Multi-AZ, backup được chụp từ standby, nên không ảnh hưởng hiệu năng của primary — quan trọng với 10 instance đang đọc nặng như trong đề.

B — cross-Region read replica: chống mất cả một Region. Đây là biện pháp cho thảm hoạ ở quy mô lớn nhất:

Region chính  (ap-southeast-1)  ─── sao chép bất đồng bộ ───→  Region dự phòng (us-east-1)
     ↓ sự cố toàn Region
Promote replica → thành CSDL độc lập ghi được

Nó cũng có lợi ích phụ khớp với đề: replica phục vụ tải đọc, giảm áp lực cho primary.

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

• A. "Automated backup trong Multi-AZ tạo backup xuyên nhiều Region" — sai về mặt sự thật. Automated backup của RDS nằm trong một Region. Muốn có bản sao ở Region khác thì phải bật cross-Region automated backup (một tính năng riêng) hoặc copy snapshot thủ công.
• C. Dùng Provisioned IOPS thay General Purpose SSD — quyết định về hiệu năng lưu trữ, hoàn toàn không liên quan tới khôi phục thảm hoạ. Đĩa nhanh hơn không giúp gì khi Region sập.
• E. Database cloning của RDS DB cluster — tính năng của Aurora (copy-on-write clone), dùng để tạo môi trường test nhanh từ dữ liệu production. Nó nằm trong cùng Region và cùng cluster, nên không phải công cụ DR. Ngoài ra đề nói RDS PostgreSQL, không phải Aurora.

Ghi nhớ

Bảng công cụ DR cho RDS, theo kịch bản: | Kịch bản thảm hoạ | Công cụ | |---|---| | Xoá nhầm, hỏng dữ liệu | automated backup + PITR | | Hỏng một AZ | Multi-AZ (failover tự động 1–2 phút) | | Hỏng cả Region | cross-Region read replica hoặc cross-Region backup | | Cần giữ lâu hơn 35 ngày | manual snapshot hoặc AWS Backup |

Nguyên tắc: backup chống lỗi logic; replica chống lỗi hạ tầng. Chúng không thay thế nhau — một hệ thống nghiêm túc cần cả hai.

Đáp án

D — Load balancer chưa bật stickiness (sticky session).

Vì sao đúng

Triệu chứng rất đặc trưng: hoạt động bình thường ở máy local nhưng lỗi khi có load balancer — và người dùng bị đăng xuất khi chuyển trang.

Nguyên nhân: ứng dụng lưu dữ liệu phiên trên chính instance (trong bộ nhớ hoặc trên đĩa). Với 10 instance sau ALB, mỗi request có thể tới một máy khác:

Request 1 (đăng nhập) → Instance 3   → tạo phiên, lưu tại chỗ
Request 2 (chuyển trang) → Instance 7 → KHÔNG BIẾT phiên này → bắt đăng nhập lại

Ở máy local chỉ có một tiến trình nên vấn đề không bao giờ lộ ra.

Sticky session chữa bằng cách ghim mỗi client vào cùng một target:

aws elbv2 modify-target-group-attributes --target-group-arn <arn> \
  --attributes Key=stickiness.enabled,Value=true \
               Key=stickiness.type,Value=lb_cookie \
               Key=stickiness.lb_cookie.duration_seconds,Value=86400

Nhưng cần nói rõ: đây là cách chữa triệu chứng. Sticky session có ba nhược điểm thật:

• Tải phân bố lệch — client hoạt động nhiều dồn vào một instance
• Instance chết là phiên mất — người dùng vẫn bị đăng xuất
• Deploy kiểu immutable/blue-green là mất hết phiên — vì instance bị thay

Cách chữa gốc là tách trạng thái ra khỏi instance: lưu phiên vào ElastiCache hoặc DynamoDB. Khi ấy mọi instance đều phục vụ được mọi request, và không cần sticky session nữa.

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

• B. "Instance không thấy IP client vì có load balancer" — ứng dụng không định danh phiên bằng IP (làm vậy sẽ hỏng với mọi người dùng sau NAT hoặc mạng di động). Và IP client vẫn lấy được qua header X-Forwarded-For.
• C. "Load balancer chưa bật TLS" — TLS bảo vệ dữ liệu khi truyền; nó không liên quan gì tới việc phiên có được nhận ra hay không. Không có TLS thì phiên vẫn hoạt động (chỉ là kém an toàn).
• A. "ALB đang ở slow-start mode" — slow-start là tính năng tăng dần lưu lượng cho target mới thêm vào, để nó kịp làm nóng. Nó không liên quan tới việc đọc ghi dữ liệu phiên; mô tả trong phương án là bịa.

Ghi nhớ

Nguyên tắc lớn hơn: hạ tầng co giãn đòi ứng dụng không trạng thái. Sticky session là giải pháp tạm thời cho ứng dụng cũ; thiết kế mới nên tách trạng thái ra ngay từ đầu.

Đáp án

D và E.

• D — Standard Workflow hợp với quy trình chạy dài, bền bỉ, kiểm toán được, và có hỗ trợ bước phê duyệt của con người.
• E — Dùng Express Workflow cho workload có tần suất sự kiện cao và thời lượng ngắn.

Vì sao đúng

Step Functions có hai loại workflow với đặc tính rất khác nhau:

D đúng vì hai lý do. Thứ nhất, quy trình duyệt khoản vay có thể kéo dài nhiều ngày — chỉ Standard chứa nổi. Thứ hai, và quan trọng hơn: phê duyệt của con người cần callback pattern .waitForTaskToken, và pattern đó chỉ Standard hỗ trợ:

"ChoNguoiDuyet": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:...:duyet-khoan-vay",
    "Message": {"TaskToken.$": "$$.Task.Token", "HoSo.$": "$.hoSo"}
  },
  "Next": "GiaiNgan"
}

State machine dừng lại chờ cho tới khi ai đó gọi SendTaskSuccess với token đó.

E đúng vì đó chính là mô tả trường hợp dùng của Express: xử lý luồng dữ liệu, IoT, biến đổi sự kiện — nhiều, nhanh, ngắn.

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

• B. Giống hệt D nhưng nói Standard KHÔNG hỗ trợ bước phê duyệt của con người — đảo ngược đúng điểm quan trọng nhất.
• A. "Standard tối đa 180 ngày / 6 tháng" — sai con số. Standard workflow chạy tối đa 1 năm.
• C. "Cả Standard và Express đều hỗ trợ mọi service integration, activity và design pattern" — sai. Express không hỗ trợ: .waitForTaskToken (callback), activity, và không có lịch sử thực thi trong console.

Ghi nhớ

Cách chọn nhanh: | Nhu cầu | Loại | |---|---| | Chờ người duyệt, chạy lâu, cần kiểm toán | Standard | | Tần suất rất cao, mỗi lần dưới 5 phút | Express | | Cần exactly-once | Standard | | Tối ưu chi phí cho khối lượng lớn | Express |

Ba service integration pattern của Step Functions: | Pattern | Hành vi | |---|---| | Request-Response (mặc định) | gọi rồi đi tiếp ngay | | .sync | chờ công việc hoàn tất (ECS task, Glue job…) | | .waitForTaskToken | chờ callback — dùng cho phê duyệt của con người |

Đáp án

B — Dùng AWS Step Functions state machine để điều phối quy trình.

Vì sao đúng

Đề nêu ba đặc điểm của quy trình, và cả ba đều là tính năng dựng sẵn của state machine:

{
  "StartAt": "XuLySongSong",
  "States": {
    "XuLySongSong": {
      "Type": "Parallel",
      "Branches": [
        {"StartAt": "KiemKho",    "States": {"KiemKho":    {"Type":"Task","Resource":"...kiem-kho","End":true}}},
        {"StartAt": "KiemThanhToan","States": {"KiemThanhToan":{"Type":"Task","Resource":"...thanh-toan","End":true}}},
        {"StartAt": "KiemGianLan", "States": {"KiemGianLan": {"Type":"Task","Resource":"...gian-lan","End":true}}}
      ],
      "Next": "TatCaHopLe?"
    },
    "TatCaHopLe?": {
      "Type": "Choice",
      "Choices": [{"Variable": "$.hopLe", "BooleanEquals": true, "Next": "XacNhanDon"}],
      "Default": "TuChoiDon"
    },
    "XacNhanDon": {"Type": "Task", "Resource": "...xac-nhan", "End": true},
    "TuChoiDon":  {"Type": "Task", "Resource": "...tu-choi",  "End": true}
  }
}

Kèm theo là những thứ có sẵn, không phải viết: Retry với exponential backoff cho từng bước, Catch để rẽ nhánh xử lý lỗi, và giao diện trực quan cho thấy đơn hàng đang ở bước nào.

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

• C. Step Functions activities — đây là bẫy tinh vi nhất vì nó cùng dịch vụ. Activity không phải cơ chế điều phối — nó là một kiểu Task đặc biệt dành cho worker chạy bên ngoài (trên EC2, on-premises, hoặc container tự quản) tự poll lấy việc:

  Worker gọi GetActivityTask → làm việc → gọi SendTaskSuccess
  

  Đề nói mọi tác vụ đã là Lambda, nên activity hoàn toàn không cần thiết. Và bản thân activity vẫn phải nằm bên trong một state machine.
• A. AWS Glue — dịch vụ ETL: trích xuất, biến đổi, nạp dữ liệu. Nó có workflow nhưng dành cho đường ống dữ liệu, không phải quy trình nghiệp vụ với logic rẽ nhánh.
• D. AWS Batch — chạy job tính toán theo lô trên hạ tầng do nó quản (thường là ECS/Fargate). Hợp với mô phỏng khoa học, render, xử lý dữ liệu lớn — không phải điều phối quy trình nhiều bước có điều kiện.

Ghi nhớ

Tám loại state của Amazon States Language: | State | Vai trò | |---|---| | Task | thực hiện công việc — cần Resource | | Choice | rẽ nhánh theo điều kiện | | Parallel | chạy nhiều nhánh song song | | Map | lặp qua một mảng (có distributed map cho quy mô lớn) | | Wait | chờ | | Pass | truyền dữ liệu qua | | Succeed / Fail | kết thúc |

Nhận dạng nhanh: đề nói "parallel" và "decision steps" ⇒ chính là Parallel và Choice của Step Functions state machine.

Đáp án

B — Cài và chạy X-Ray daemon trên máy chủ on-premises.

Vì sao đúng

Kiến trúc của X-Ray có một chi tiết quan trọng: SDK không gửi thẳng dữ liệu lên dịch vụ X-Ray.

Ứng dụng (X-Ray SDK)
   ↓ UDP cổng 2000, gửi CỤC BỘ
X-Ray daemon
   ↓ HTTPS, gọi PutTraceSegments
Dịch vụ AWS X-Ray

Daemon là tiến trình trung gian: nó nhận segment qua UDP, gom thành lô, rồi gửi lên AWS. Với Lambda, ECS Fargate, Elastic Beanstalk thì daemon đã có sẵn hoặc được cài tự động — nhưng với máy chủ on-premises thì phải tự cài:

curl -o xray.rpm https://s3.amazonaws.com/aws-xray-assets.../aws-xray-daemon-3.x.rpm
sudo yum install -y xray.rpm
sudo systemctl start xray

Và vì máy nằm ngoài AWS, phải cấp thông tin xác thực cho daemon:

# ~/.aws/credentials  (hoặc dùng SSM hybrid activation — an toàn hơn)
[default]
region = ap-southeast-1

Quyền cần: AWSXRayDaemonWriteAccess (xray:PutTraceSegments, xray:PutTelemetryRecords).

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

• D. "Cài X-Ray SDK trên máy chủ để thu thập và chuyển dữ liệu" — bẫy sát nhất. SDK có vai trò: nó tạo segment và đo thời gian. Nhưng nó gửi qua UDP tới daemon cục bộ, chứ không tự gửi lên dịch vụ X-Ray. Không có daemon thì segment rơi vào hư không — và không có lỗi nào hiện ra, vì SDK cố ý nuốt lỗi để không làm hỏng ứng dụng.
• A. CloudWatch Unified Agent — thu thập metric và log của hệ điều hành. Nó không xử lý trace của X-Ray, và không gọi PutTraceSegments.
• C. Lambda phân tích lưu lượng rồi chuyển tiếp — kiến trúc vòng vèo và bịa: Lambda không có cách nào "phân tích lưu lượng đến" trên một máy chủ on-premises. Và PutTelemetryRecords gửi số liệu vận hành của daemon, không gửi trace.

Ghi nhớ

Daemon cần ở đâu: | Nền tảng | Daemon | |---|---| | Lambda | đã có sẵn — chỉ cần bật Tracing: Active | | ECS Fargate | thêm sidecar container chạy daemon | | Elastic Beanstalk | bật trong cấu hình môi trường | | EC2 | tự cài | | On-premises | tự cài + cấp thông tin xác thực |

Danh sách kiểm khi X-Ray không có dữ liệu:

1. Daemon đã chạy chưa?
2. Quyền xray:PutTraceSegments đã có chưa?
3. UDP cổng 2000 có bị chặn không?
4. Instrumentation của SDK đã bật chưa?