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

Đáp án

D — Worker environment riêng (dedicated worker environment).

Vì sao đúng

Elastic Beanstalk có hai kiểu môi trường, và chúng phục vụ hai mục đích khác nhau:

Worker environment làm đúng điều đề cần: Beanstalk tự tạo một SQS queue, cài sẵn một daemon (sqsd) trên mỗi instance để kéo message từ queue và POST chúng tới ứng dụng của bạn ở localhost:

Web tier  →  gửi message vào SQS  →  trả lời client NGAY (không chờ)
                                        ↓
Worker tier  ←  sqsd kéo message  ←  SQS
             →  POST http://localhost/ →  xử lý (có thể mất nhiều phút)

Nhờ vậy tầng web luôn phản hồi nhanh dù tác vụ nền chạy bao lâu — chính xác điều mà quản lý yêu cầu ("ensure software applications stay responsive under load").

Worker environment còn cấu hình được visibility timeout, retry, DLQ và định kỳ theo cron (cron.yaml) — tất cả qua giao diện Beanstalk.

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

• A. "Single Instance Worker node" — worker environment có chạy được ở chế độ single instance, nhưng đó là cấu hình về số lượng máy, không phải kiểu môi trường. Với tải nặng như đề mô tả, một instance duy nhất là điểm nghẽn và điểm hỏng đơn lẻ. Cách diễn đạt cũng không phải một lựa chọn kiểu môi trường chuẩn.
• B. Single Instance với Elastic IP — đây là web server environment ở dạng đơn giản nhất, không có load balancer. Nó không tích hợp SQS và không có daemon kéo message.
• C. Load-balancing, Autoscaling environment — đây là web server environment đầy đủ. Nó phục vụ HTTP request rất tốt, nhưng không có cơ chế tiêu thụ SQS — bạn sẽ phải tự viết vòng lặp polling, tự quản visibility timeout, tự xử lý retry.

Ghi nhớ

Mẫu kiến trúc chuẩn với Beanstalk:

Web server environment  (nhận request, trả lời ngay)
        ↓ SendMessage
     SQS queue
        ↓ sqsd kéo
Worker environment      (xử lý nặng, không ai chờ)

Hai tệp cấu hình đặc trưng của worker environment: | Tệp | Vai trò | |---|---| | cron.yaml | lên lịch tác vụ định kỳ | | .ebextensions/*.config | cấu hình aws:elasticbeanstalk:sqsd — visibility timeout, số kết nối, đường dẫn HTTP đích |

Nguyên tắc lớn hơn: tách việc chậm ra khỏi đường đi của request. Đây cũng là lý do tồn tại của SQS, Step Functions và các hàng đợi nền nói chung.

Đáp án

C — Dùng IAM role.

Vì sao đúng

Đây là quy tắc bất di bất dịch của AWS: compute luôn dùng role, không bao giờ dùng khoá tĩnh.

Gắn instance profile vào EC2 thì AWS SDK tự động lấy thông tin xác thực từ metadata service, không cần cấu hình gì trong mã:

import boto3
s3 = boto3.client('s3')                    # tự tìm thấy thông tin xác thực
s3.get_object(Bucket='don-hang', Key='2026-08-27.json')

So sánh hai cách:

Policy nên hẹp tới đúng mức cần:

{"Effect": "Allow", "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::don-hang/*"}

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

• D. Tạo IAM user rồi cất access key vào ~/.aws/credentials — đây là bẫy chính vì nó chạy được, nên nhiều người chọn. Nhưng nó kém an toàn ở mọi mặt: khoá nằm trên đĩa (ai vào được máy là lấy được), không tự hết hạn, phải xoay vòng thủ công, và nếu AMI được nhân bản thì khoá đi theo sang mọi instance mới.
• B. Bucket policy cho phép truy cập công khai — phơi bày dữ liệu đơn hàng ra Internet. Đây là sự cố bảo mật nghiêm trọng, không phải giải pháp.
• A. EC2 User Data — user data là script chạy lúc boot, không phải cơ chế xác thực. Tệ hơn: nếu ý là nhét khoá vào user data thì đó là cách cất bí mật tồi nhất — mọi tiến trình trên máy đọc được qua http://169.254.169.254/latest/user-data, kể cả ứng dụng đã bị chiếm quyền.

Ghi nhớ

Mỗi loại compute có cơ chế role riêng: | Compute | Cơ chế | |---|---| | EC2 | instance profile | | Lambda | execution role | | ECS | task role | | EKS | IRSA hoặc Pod Identity | | CodeBuild | service role | | On-premises | SSM hybrid activation (không phải access key) |

Mẹo làm bài: thấy "access key" trong ngữ cảnh dịch vụ AWS gọi dịch vụ AWS thì gần như chắc chắn loại được phương án đó.

Đáp án

D — Dùng Amazon CloudFront.

Vì sao đúng

Manh mối chẩn đoán rất rõ: người dùng ở Mỹ có trải nghiệm tốt, người dùng ở nơi khác thì chậm. Bucket S3 nằm ở một Region duy nhất (nhiều khả năng ở Mỹ), nên vấn đề là khoảng cách địa lý, không phải năng lực.

CloudFront là CDN của AWS, giải quyết đúng vấn đề đó bằng cách cache nội dung tại hơn 600 edge location trên toàn thế giới:

Trước:  Người dùng Úc → (~200 ms) → S3 ở us-east-1
Sau  :  Người dùng Úc → (~15 ms)  → CloudFront edge ở Sydney

Với trang tĩnh HTML5 như trong đề, đây là trường hợp lý tưởng: mọi thứ đều cache được — HTML, CSS, JavaScript, ảnh. Tỷ lệ trúng cache gần như tuyệt đối.

Ba lợi ích đi kèm:

• Giảm chi phí — request được phục vụ từ cache không tính vào request của S3, và phí truyền dữ liệu từ CloudFront rẻ hơn
• Bảo mật — dùng Origin Access Control (OAC) để bucket đóng hoàn toàn, chỉ CloudFront đọc được
• HTTPS và tên miền tuỳ chỉnh — miễn phí qua ACM

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

• B. S3 Transfer Acceleration — đây là bẫy sát nhất, và khác biệt rất quan trọng: Transfer Acceleration tối ưu cho việc TẢI LÊN (upload) từ xa, bằng cách đi qua edge location rồi dùng mạng lưng AWS về bucket. Nó không cache gì cả, nên với hàng nghìn người dùng tải xuống cùng một trang, mỗi request vẫn phải về tận Region gốc.

  	Transfer Acceleration	CloudFront
  Tối ưu cho	upload	download
  Cache	❌	✅
  Hợp với	tải tệp lớn lên từ xa	phân phối nội dung

• C. "Amazon S3 Caching" — không tồn tại. S3 không có tính năng cache tích hợp; cơ chế cache cho S3 chính là đặt CloudFront phía trước.

• A. ElastiCache for Redis — cache trong bộ nhớ cho ứng dụng, nằm trong VPC ở một Region. Nó không phục vụ nội dung web cho người dùng cuối và không có mặt ở edge location.

Ghi nhớ

Mẫu chuẩn cho trang tĩnh toàn cầu: S3 (private, OAC) + CloudFront + ACM + Route 53, thêm WAF nếu cần chống lỗ hổng web.

Đáp án

B — Tổng kích thước tất cả biến môi trường không được vượt quá 4 KB; không có giới hạn về số lượng biến.

Vì sao đúng

Lambda chỉ đặt một ràng buộc cho biến môi trường, và đó là ràng buộc về tổng dung lượng:

Con số 4 KB tính trên toàn bộ tên và giá trị cộng lại. Nên trong thực tế, số biến bạn tạo được phụ thuộc vào độ dài của chúng:

50 biến × trung bình 80 byte = 4.000 byte  → vừa đủ
50 biến × trung bình 100 byte = 5.000 byte → VƯỢT, deploy thất bại

Với tình huống trong đề — hơn 50 biến chứa tên bảng CSDL — con số 4 KB rất dễ chạm tới.

Và có một điểm bảo mật quan trọng cần nêu: đề nói các biến chứa "sensitive information". Biến môi trường của Lambda không phải nơi cất bí mật: chúng hiện nguyên văn trong Console và trong GetFunctionConfiguration với bất kỳ ai có quyền đọc cấu hình hàm.

Cách đúng cho dữ liệu nhạy cảm — và nó cũng giải quyết luôn vấn đề 4 KB:

tham_so = ssm.get_parameters_by_path(Path='/ung-dung/prod/', WithDecryption=True)

Chỉ cần một biến môi trường (tên môi trường), phần còn lại lấy từ Parameter Store hoặc Secrets Manager.

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

• A. "8 KB, không giới hạn số lượng" — đúng vế thứ hai, sai con số. Giới hạn là 4 KB.
• C. "8 KB, tối đa 50 biến" — sai cả hai vế.
• D. "4 KB, tối đa 35 biến" — đúng con số 4 KB nhưng bịa ra giới hạn 35 biến, vốn không tồn tại.

Ghi nhớ

Các giới hạn của Lambda hay bị hỏi: | Giới hạn | Giá trị | |---|---| | Biến môi trường (tổng) | 4 KB | | Gói triển khai (zip tải lên trực tiếp) | 50 MB | | Gói giải nén | 250 MB | | Container image | 10 GB | | /tmp | 512 MB – 10.240 MB | | Timeout | tối đa 15 phút | | Bộ nhớ | 128 MB – 10.240 MB | | Payload (đồng bộ) | 6 MB | | Payload (bất đồng bộ) | 256 KB |

Nguyên tắc thực dụng: biến môi trường dùng cho cấu hình không nhạy cảm và ngắn gọn (tên môi trường, mức log, cờ tính năng). Mọi thứ khác đi qua Parameter Store hoặc Secrets Manager.

Đáp án

B — Dùng SQS Extended Client Library.

Vì sao đúng

SQS có giới hạn cứng 256 KB mỗi message, và không nâng được bằng cách xin service quota.

Amazon SQS Extended Client Library giải quyết bằng mẫu claim check: payload lớn cất ở S3, còn hàng đợi chỉ mang một con trỏ:

Producer:
  1. Ghi payload lớn vào S3
  2. Gửi vào SQS một message nhỏ chứa: bucket + key

Consumer:
  3. Nhận message, đọc con trỏ
  4. Tải payload thật từ S3
  5. Xoá cả message lẫn object S3

Thư viện làm toàn bộ việc đó một cách trong suốt — mã của bạn vẫn gọi sendMessage và receiveMessage như thường:

AmazonSQSExtendedClient sqs = new AmazonSQSExtendedClient(
    AmazonSQSClientBuilder.defaultClient(),
    new ExtendedClientConfiguration()
        .withPayloadSupportEnabled(s3Client, "kho-payload-lon")
        .withAlwaysThroughS3(false));      // chỉ dùng S3 khi message vượt 256 KB
sqs.sendMessage(new SendMessageRequest(queueUrl, payloadRatLon));

Với withAlwaysThroughS3(false), message nhỏ vẫn đi thẳng qua SQS như bình thường — chỉ message lớn mới vòng qua S3. Giới hạn mới là 2 GB, tức là giới hạn của S3.

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

• D. Xin AWS nâng service limit — 256 KB là giới hạn cứng của giao thức SQS, không nâng được. Đây không phải service quota.
• A. "MultiPart API" — SQS không có multipart. Multipart upload là khái niệm của S3, dùng để tải object lớn lên theo nhiều phần. SQS không chia nhỏ message.
• C. Nén bằng gzip — đây là phương án hợp lý một phần và đáng nhắc tới: nén có giúp nếu payload là văn bản hoặc JSON, có thể giảm 70–90%. Nhưng nó không phải giải pháp bền vững: payload tiếp tục tăng thì lại vượt trần, và nén không giúp gì với dữ liệu vốn đã nén (ảnh, video, tệp zip). Đề nói payload đang tăng dần, nên cần giải pháp không có trần.

Ghi nhớ

Mẫu claim check áp dụng cho nhiều dịch vụ có giới hạn payload: | Dịch vụ | Giới hạn | Cách vượt | |---|---|---| | SQS | 256 KB | Extended Client + S3 | | SNS | 256 KB | Extended Client + S3 | | Kinesis Data Streams | 1 MB mỗi bản ghi | con trỏ tới S3 | | Lambda (đồng bộ) | 6 MB | con trỏ tới S3 | | Step Functions | 256 KB state | con trỏ tới S3 |

Nguyên tắc chung: đừng đẩy dữ liệu lớn qua hệ thống nhắn tin — đẩy con trỏ. Nó rẻ hơn, nhanh hơn, và không có trần.

Đáp án

A — Cấu hình Lambda kết nối vào VPC ở private subnet với security group cho phép truy cập RDS.

Vì sao đúng

RDS nằm trong private subnet, nghĩa là nó không có địa chỉ IP công khai và không thể tới được từ Internet. Mặc định, Lambda chạy trong một môi trường do AWS quản lý bên ngoài VPC của bạn — nên nó cũng không tới được.

Cách chữa: gắn Lambda vào VPC. Khi ấy Lambda tạo ENI trong các subnet bạn chỉ định và có địa chỉ IP riêng trong VPC, nên nói chuyện được với RDS:

VpcConfig:
  SubnetIds: [subnet-private-1a, subnet-private-1c]
  SecurityGroupIds: [sg-lambda]

Kèm theo là security group của RDS phải cho phép:

aws ec2 authorize-security-group-ingress --group-id sg-rds \
  --protocol tcp --port 1433 --source-group sg-lambda   # SQL Server

Hai điểm đáng lưu ý khi gắn Lambda vào VPC:

• Nên chọn ít nhất hai subnet ở hai AZ để có tính sẵn sàng cao
• Hàm trong VPC mất quyền truy cập Internet — cần gọi ra ngoài thì phải có NAT gateway hoặc VPC endpoint cho dịch vụ đó

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

• D. Đưa Lambda vào public subnet để có Internet rồi dùng security group truy cập RDS — hiểu sai cách mạng hoạt động. Đặt Lambda ở public subnet không tự cho nó truy cập RDS ở private subnet; và ngay cả khi cùng VPC thì việc "có Internet" chẳng liên quan gì. (Thực tế còn ngược: Lambda trong public subnet vẫn không có Internet, vì ENI của Lambda không được gán IP công khai — muốn ra Internet vẫn phải qua NAT gateway.)
• C. Truyền chuỗi kết nối qua biến môi trường — cần thiết về mặt cấu hình, nhưng không giải quyết vấn đề mạng. Biết địa chỉ RDS mà không có đường đi tới nó thì kết nối vẫn timeout.
• B. "Dùng Lambda layer để kết nối Internet và RDS" — hiểu sai hoàn toàn layer. Layer chỉ là cách đóng gói thư viện dùng chung; nó không có bất kỳ vai trò nào về mạng.

Ghi nhớ

Danh sách kiểm khi Lambda không kết nối được RDS:

1. Lambda đã gắn vào VPC chưa? (VpcConfig)
2. Có chọn subnet cùng VPC với RDS không?
3. Security group của RDS có cho phép security group của Lambda vào đúng cổng không?
4. Execution role có AWSLambdaVPCAccessExecutionRole chưa? (cần để tạo ENI)
5. Nếu hàm còn gọi dịch vụ AWS khác: có NAT gateway hoặc VPC endpoint chưa?

Và một khuyến nghị kiến trúc: với Lambda + RDS, hãy dùng RDS Proxy. Lambda mở rộng rất nhanh và dễ làm cạn connection pool của CSDL; RDS Proxy gộp và tái sử dụng kết nối, giải quyết đúng vấn đề đó.

Đáp án

B — Tạo một CodePipeline duy nhất cho toàn bộ quy trình và thêm một manual approval step.

Vì sao đúng

Yêu cầu: quy trình phát hành từ mã tới triển khai nằm trong tay đội phát triển, còn trưởng nhóm chịu trách nhiệm phê duyệt thủ công.

Manual approval action của CodePipeline làm đúng việc đó — nó đặt một cổng chặn ở đúng chỗ bạn muốn:

{
  "name": "Duyet-Truoc-PROD",
  "actionTypeId": {"category": "Approval", "owner": "AWS",
                   "provider": "Manual", "version": "1"},
  "configuration": {
    "NotificationArn": "arn:aws:sns:...:duyet-deploy",
    "CustomData": "Xem kết quả kiểm thử ở staging trước khi duyệt",
    "ExternalEntityLink": "https://bao-cao-kiem-thu/..."
  }
}

Pipeline dừng lại và chờ, gửi thông báo SNS cho trưởng nhóm, và chỉ đi tiếp khi có người bấm duyệt. Quyền duyệt kiểm soát bằng IAM (codepipeline:PutApprovalResult), nên chỉ đúng người được phép.

Vì sao một pipeline duy nhất. Toàn bộ quy trình từ mã tới production là một luồng giá trị, nên nên nằm trong một pipeline: nhìn thấy toàn cảnh ở một chỗ, artifact chảy liên tục qua các stage, và cổng phê duyệt đặt được ở bất kỳ ranh giới nào.

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

• C. Nhiều pipeline nối nhau bằng Lambda — chia nhỏ một luồng vốn liền mạch, rồi phải tự viết mã để nối chúng lại. Mất cái nhìn tổng thể, thêm chỗ để hỏng, và không được gì thêm.
• D. "Nhiều pipeline tích hợp sâu cho từng môi trường" — mơ hồ và cùng vấn đề với C: nhiều pipeline nghĩa là nhiều nơi phải cấu hình, nhiều nơi phải sửa khi quy trình thay đổi.
• A. CodePipeline với Amazon VPC — không liên quan. VPC là cấu hình mạng; nó chẳng nói gì về phê duyệt thủ công. (CodeBuild có thể chạy trong VPC khi cần truy cập tài nguyên riêng, nhưng đó là chuyện khác hẳn.)

Ghi nhớ

Đặc điểm của manual approval trong CodePipeline: | Đặc điểm | Chi tiết | |---|---| | Timeout | 7 ngày — quá hạn thì action thất bại | | Thông báo | SNS topic, hoặc AWS Chatbot cho Slack/Chime | | Ngữ cảnh | CustomData (ghi chú) và ExternalEntityLink (link tới báo cáo) | | Quyền | IAM action codepipeline:PutApprovalResult | | Vị trí | đặt được ở bất kỳ stage nào |

Mẫu thường dùng: build → test tự động → deploy staging → [manual approval] → deploy production. Cổng người đặt ngay trước production, sau khi mọi kiểm thử tự động đã xanh.

Đáp án

B — Amazon ECS trên Fargate.

Vì sao đúng

Đề đòi ba thứ: chạy Docker container, trên kiến trúc serverless, và cách đơn giản nhất, ít công sức nhất.

ECS trên Fargate đáp ứng cả ba:

Bạn khai container cần chạy, Fargate lo phần còn lại: cấp năng lực tính toán, vá hệ điều hành nền, mở rộng, thay task chết. Trả tiền theo vCPU và bộ nhớ mà task thực sự dùng, tính theo giây.

{
  "family": "ung-dung",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512", "memory": "1024",
  "containerDefinitions": [{"name": "app", "image": "...ecr.../app:v1"}]
}

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

• A. ECS trên EC2 — không serverless: bạn vẫn phải quản cụm EC2 (vá, tính dung lượng cluster, xử lý instance hỏng, cấu hình capacity provider), và trả tiền theo giờ instance kể cả lúc rảnh. Đề nói rõ công ty muốn rời khỏi việc đặt trước EC2.
• D. EKS trên Fargate — cũng serverless và cũng chạy container, nhưng phức tạp hơn hẳn: phải hiểu Kubernetes (pod, deployment, service, ingress, RBAC), và EKS còn tính phí control plane cố định ~0,10 USD/giờ mỗi cluster. Đề nhấn mạnh "simplest and the least effort" — EKS đáng chọn khi đội đã quen Kubernetes hoặc cần tính di động đa đám mây, không phải khi tiêu chí là đơn giản nhất.
• C. Elastic Beanstalk — có hỗ trợ Docker, nhưng nó dựng EC2 bên dưới, tức là quay lại đúng thứ công ty muốn tránh. Beanstalk cũng là lớp trừu tượng hướng ứng dụng, không hướng container.

Ghi nhớ

Vài giới hạn của Fargate cần biết: không dùng được GPU, không dùng được EC2 Spot theo kiểu truyền thống (có Fargate Spot riêng), và không truy cập được host — nên workload cần daemon đặc biệt hoặc quyền đặc quyền thì vẫn phải dùng EC2.

Đáp án

B — Dùng SSM Parameter Store.

Vì sao đúng

Vấn đề với .ebextensions: các tệp .config nằm trong gói mã nguồn, nên mọi thay đổi cấu hình đều đòi deploy lại toàn bộ ứng dụng. Đó chính xác là điều đội DevOps muốn tránh.

Parameter Store tách cấu hình ra khỏi mã, và ứng dụng đọc nó lúc chạy:

moi_truong = os.environ['MOI_TRUONG']
tham_so = ssm.get_parameters_by_path(
    Path=f'/ung-dung/{moi_truong}/',
    Recursive=True,
    WithDecryption=True)

Ba yêu cầu của đề được đáp ứng đúng từng cái:

Tổ chức theo đường dẫn phân cấp để mỗi môi trường một nhánh:

/ung-dung/dev/db-host
/ung-dung/prod/db-host
/ung-dung/prod/api-key      ← SecureString

Một lời gọi GetParametersByPath lấy cả nhánh, và phân quyền cũng theo prefix — nên môi trường này không đọc được tham số của môi trường kia.

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

• D. Biến môi trường — Beanstalk có biến môi trường, nhưng thay đổi chúng làm môi trường cập nhật và khởi động lại instance — vẫn là gián đoạn, vẫn không phải "nạp động". Chúng cũng hiện nguyên văn trong Console, không phù hợp cho dữ liệu nhạy cảm.
• A. Dùng S3 — lưu được tệp cấu hình và đọc lúc chạy, nhưng thiếu hẳn phần quản lý: không có phiên bản theo tham số, không có SecureString, không có phân quyền ở mức từng khoá, và bạn phải tự viết phần phân tích tệp.
• C. Stage variable — khái niệm của API Gateway, không phải của Elastic Beanstalk. Sai dịch vụ hoàn toàn.

Ghi nhớ

Mẹo hiệu năng: cache giá trị trong bộ nhớ với TTL ngắn thay vì gọi Parameter Store ở mỗi request — vừa nhanh hơn vừa tránh chạm giới hạn tần suất API.

Đáp án

A — Chèn câu lệnh ghi log vào mã Lambda; chúng xuất hiện trong CloudWatch Logs.

Vì sao đúng

Đây là cơ chế nền tảng và cũng là công cụ gỡ lỗi chính cho Lambda: mọi thứ hàm ghi ra stdout/stderr đều tự động chảy vào CloudWatch Logs.

Không cần cấu hình gì — Lambda tạo sẵn log group /aws/lambda/<tên-hàm> và ghi vào đó, miễn là execution role có quyền cơ bản (AWSLambdaBasicExecutionRole).

import logging, json
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def handler(event, context):
    logger.info(json.dumps({'buoc': 'bat_dau', 'request_id': context.aws_request_id}))
    try:
        kq = xu_ly(event)
        logger.info(json.dumps({'buoc': 'xong', 'ket_qua': kq}))
        return kq
    except Exception as e:
        logger.error(json.dumps({'buoc': 'loi', 'chi_tiet': str(e)}), exc_info=True)
        raise

Ghi log dạng JSON có cấu trúc rất đáng làm, vì khi đó Logs Insights truy vấn được theo trường:

fields @timestamp, buoc, chi_tiet
| filter buoc = "loi"
| sort @timestamp desc

Lambda cũng tự ghi sẵn dòng REPORT cho mỗi lần chạy, kèm thời gian chạy, bộ nhớ dùng, thời gian init — rất hữu ích để phát hiện cold start và hàm sắp hết bộ nhớ.

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

• D. CloudWatch Events (EventBridge) — định tuyến sự kiện, không thu thập log. Nó có thể phản ứng khi hàm lỗi (qua metric alarm hoặc destination), nhưng nó không cho biết lỗi là gì — mà đó mới là điều cần để "actively troubleshoot".
• B. CodeCommit — dịch vụ lưu trữ mã nguồn (Git). Nó không biết gì về việc hàm chạy ra sao.
• C. CodeDeploy — dịch vụ triển khai. Nó theo dõi được deployment thành công hay thất bại, nhưng không theo dõi lỗi lúc chạy sau khi deploy đã xong.

Ghi nhớ

Bộ công cụ quan sát cho Lambda, dùng chồng lên nhau: | Công cụ | Cho biết | |---|---| | CloudWatch Logs | hàm đã ghi gì — nguồn gỡ lỗi chính | | CloudWatch Metrics | Invocations, Errors, Duration, Throttles, ConcurrentExecutions | | X-Ray | request đi qua đâu, chậm ở chặng nào | | DLQ / on-failure destination | giữ lại sự kiện gây lỗi để tái hiện | | Lambda Insights | metric hệ thống chi tiết (CPU, bộ nhớ, mạng) |

Hai khuyến nghị vận hành: đặt retention cho log group (mặc định là giữ mãi mãi, rất tốn tiền), và luôn cấu hình DLQ hoặc destination cho hàm chạy bất đồng bộ — nếu không, sự kiện gây lỗi biến mất và bạn không tái hiện được.