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

Đáp án

D — Dùng Cognito Authentication qua Cognito User Pools cho Application Load Balancer.

Vì sao đúng

Yêu cầu: tách hẳn việc xác thực ra khỏi ứng dụng, với ít công sức phát triển nhất.

ALB có tính năng xác thực tích hợp sẵn — nó xử lý toàn bộ luồng OIDC trước khi request tới instance:

Client → ALB ──(chưa đăng nhập)──→ chuyển hướng tới Cognito hosted UI
              ──(đã đăng nhập)───→ EC2, kèm header chứa thông tin người dùng

ALB thêm ba header cho backend: | Header | Nội dung | |---|---| | x-amzn-oidc-data | JWT chứa claim của người dùng | | x-amzn-oidc-identity | ID người dùng (sub) | | x-amzn-oidc-accesstoken | access token |

Nhờ vậy ứng dụng không phải viết một dòng mã xác thực nào — nó chỉ đọc header và tin vào đó. Đúng nghĩa "minimal development effort".

Cấu hình là một listener rule:

{"Type": "authenticate-cognito",
 "AuthenticateCognitoConfig": {
   "UserPoolArn": "arn:aws:cognito-idp:...:userpool/ap-southeast-1_xxx",
   "UserPoolClientId": "abc123",
   "UserPoolDomain": "ung-dung-anh"}}

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

• C. Cognito Identity Pools cho ALB — ALB không hỗ trợ identity pool. Nó chỉ nhận Cognito user pool hoặc OIDC provider làm nguồn xác thực. Và identity pool vốn không phải cơ chế xác thực — nó đổi danh tính đã xác thực lấy thông tin xác thực AWS.
• A và B. Cognito Authentication cho CloudFront — CloudFront không có tính năng xác thực tích hợp. Muốn xác thực ở edge thì phải tự viết Lambda@Edge hoặc CloudFront Functions kiểm token — nhiều công sức hơn hẳn, trái yêu cầu của đề.

Ghi nhớ

Các tầng có thể xử lý xác thực, và mức công sức: | Tầng | Cơ chế | Công sức | |---|---|---| | ALB | authenticate-cognito, authenticate-oidc | thấp nhất — cấu hình | | API Gateway | Cognito authorizer, Lambda authorizer | thấp | | CloudFront | Lambda@Edge tự viết | cao | | Ứng dụng | tự cài đặt | cao nhất |

Và phân biệt lại cặp Cognito hay lẫn: | | User Pool | Identity Pool | |---|---|---| | Là gì | thư mục người dùng | bộ đổi danh tính | | Phát ra | JWT | thông tin xác thực AWS tạm thời | | ALB hỗ trợ | ✅ | ❌ |

Đáp án

A — Chạy CodeBuild cục bộ bằng CodeBuild Agent.

Vì sao đúng

CodeBuild Local Agent là một Docker image chính thức của AWS cho phép chạy build ngay trên máy của bạn, dùng đúng môi trường và đúng buildspec.yml như trên cloud:

# Tải script và image
curl -O https://raw.githubusercontent.com/aws/aws-codebuild-docker-images/master/local_builds/codebuild_build.sh
chmod +x codebuild_build.sh

# Chạy build cục bộ
./codebuild_build.sh \
  -i public.ecr.aws/codebuild/amazonlinux2-x86_64-standard:5.0 \
  -a /tmp/artifacts \
  -s /duong/dan/ma-nguon

Ba lợi ích khớp đúng với yêu cầu "quickly troubleshoot": | Lợi ích | Chi tiết | |---|---| | Vòng lặp nhanh | sửa buildspec, chạy lại ngay, không phải commit và push | | Xem được toàn bộ output | mọi lệnh, mọi biến môi trường | | Vào được container | dừng ở giữa và khảo sát trạng thái | | Miễn phí | không tốn phút build trên AWS |

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

• B. SSH vào container CodeBuild — không làm được với CodeBuild chạy trên cloud: bạn không có quyền truy cập vào môi trường build do AWS quản lý. (Có một ngoại lệ hiện đại: CodeBuild session manager cho phép "break point" và kết nối vào build đang chạy — nhưng nó không phải SSH, và phải bật tường minh bằng codebuild-breakpoint trong buildspec.)
• C. "Đóng băng CodeBuild ở lần chạy tiếp theo" — không có tính năng nào tên như vậy. Thứ gần nhất là codebuild-breakpoint đã nói ở trên.
• D. Bật detailed monitoring — khái niệm của EC2 (đổi chu kỳ metric từ 5 phút xuống 1 phút). CodeBuild không có thiết lập này, và metric cũng không cho biết lệnh nào trong buildspec gây lỗi.

Ghi nhớ

Công cụ gỡ lỗi CodeBuild, theo thứ tự nên thử: | Công cụ | Dùng khi | |---|---| | CloudWatch Logs của build | luôn xem đầu tiên — có output của mọi lệnh | | Local Agent | lặp nhanh khi sửa buildspec | | codebuild-breakpoint + Session Manager | cần khảo sát trạng thái giữa chừng trên cloud | | Báo cáo test (reports) | phân tích kết quả kiểm thử |

Mẹo thực dụng: thêm set -x vào đầu phần commands để in ra mọi lệnh trước khi chạy, và dùng khối finally để in thông tin chẩn đoán kể cả khi build thất bại:

phases:
  build:
    commands: [mvn package]
    finally: [ls -la target/, cat target/surefire-reports/*.txt]

Đáp án

A — Đổi health check type của Auto Scaling group từ EC2 sang ELB, bằng một tệp cấu hình.

Vì sao đúng

Đây là chi tiết bị bỏ quên nhiều nhất trong cấu hình Auto Scaling.

ASG có hai loại health check, và chúng kiểm tra hai thứ hoàn toàn khác nhau:

Với health check type EC2 (mặc định), ASG chỉ hỏi: "instance có đang chạy không?". Nên khi ứng dụng chết mà máy vẫn bật, ASG coi instance đó hoàn toàn khoẻ mạnh — dù ELB đã đánh dấu nó unhealthy và ngừng gửi traffic.

Đó chính xác là tình huống trong đề: hai hệ thống nhìn hai thứ khác nhau, và ASG không biết gì về kết luận của ELB.

Đổi sang ELB thì ASG kế thừa kết luận của load balancer và tự thay instance:

# .ebextensions/autoscaling.config
option_settings:
  aws:autoscaling:asg:
    HealthCheckType: ELB
    HealthCheckGracePeriod: 300

HealthCheckGracePeriod cũng quan trọng: nó cho instance mới thời gian khởi động trước khi bị đánh giá — thiếu nó thì ASG có thể huỷ instance đang khởi động, gây vòng lặp tạo–huỷ.

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

• B. "ASG không tự thay instance unhealthy, phải làm thủ công" — sai. ASG luôn tự thay instance được đánh dấu unhealthy — vấn đề là nó chưa được cấu hình để nhìn kết luận của ELB.
• C. "Ping path của load balancer cấu hình sai" — nếu ping path sai thì ELB sẽ đánh dấu MỌI instance là unhealthy, kể cả máy khoẻ. Đề nói ELB đánh dấu một instance — tức là health check đang hoạt động đúng.
• D. "Health check chỉ kiểm tra instance, lỗi ứng dụng không được cấu hình làm tham số" — mô tả này gần đúng về triệu chứng nhưng sai về giải pháp: bạn không "thêm tham số kiểm tra ứng dụng" vào health check của ASG — bạn đổi health check type sang ELB.

Ghi nhớ

Danh sách kiểm cho tính sẵn sàng của Auto Scaling group: | Việc | Vì sao | |---|---| | HealthCheckType: ELB | ASG biết ứng dụng hỏng, không chỉ máy hỏng | | HealthCheckGracePeriod đủ dài | tránh huỷ instance đang khởi động | | Min capacity ≥ 2 | một instance là điểm hỏng đơn lẻ | | Trải trên ≥ 2 AZ | AZ sập vẫn còn AZ kia | | ELB đã bật đủ các AZ | thiếu bước này thì instance ở AZ mới không nhận traffic |

Đáp án

C — 10 RCU.

Vì sao đúng

Phép tính RCU có ba bước:

Bước 1 — làm tròn kích thước item lên bội số của 4 KB:

4 KB  →  đã là bội số của 4  →  4 KB (= 1 đơn vị)

Bước 2 — tính RCU cho một lần đọc: | Loại đọc | Quy tắc | |---|---| | Strongly consistent | 1 RCU cho mỗi 4 KB | | Eventually consistent | 0,5 RCU cho mỗi 4 KB |

Đề yêu cầu strongly consistent:

1 đơn vị × 1 RCU = 1 RCU cho mỗi lần đọc

Bước 3 — nhân với số lần đọc mỗi giây:

1 RCU × 10 lần/giây = 10 RCU

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

• D. 5 — kết quả nếu tính eventually consistent (rẻ một nửa). Nhưng đề nói rõ strongly consistent.
• A. 20 — có thể do nhân đôi nhầm, hoặc dùng công thức transactional read (× 2).
• B. 40 — không tương ứng với phép tính hợp lệ nào.

Ghi nhớ

Hai công thức cần thuộc, và chúng không đối xứng:

RCU — làm tròn lên bội số 4 KB:

Strongly consistent  : ceil(size / 4 KB)       × số_lần_đọc
Eventually consistent: ceil(size / 4 KB) ÷ 2   × số_lần_đọc
Transactional read   : ceil(size / 4 KB) × 2   × số_lần_đọc

WCU — làm tròn lên bội số 1 KB:

Ghi thường        : ceil(size / 1 KB)       × số_lần_ghi
Transactional ghi : ceil(size / 1 KB) × 2   × số_lần_ghi

Ba điểm dễ sai nhất:

1. RCU dùng 4 KB, WCU dùng 1 KB — hai con số khác nhau
2. Luôn làm tròn LÊN — item 4,1 KB tốn như item 8 KB
3. Đọc kỹ đề tìm chữ "strongly" hay "eventually" — nó quyết định nhân hay chia đôi

Câu này là biến thể đơn giản nhất vì kích thước item đúng bằng 4 KB — nhưng cùng công thức áp cho mọi kích thước.

Đáp án

C và D.

• D — Phải chỉ định ARN của một IAM role cho phép API Gateway ghi thông tin lên CloudWatch Logs.
• C — API Gateway dùng AWS STS để ghi log lên CloudWatch, nên STS phải được bật cho Region đang dùng.

Vì sao đúng

D — IAM role là bước bắt buộc. API Gateway cần một role ở mức tài khoản (không phải mức API) để ghi log:

aws apigateway update-account --patch-operations \
  op=replace,path=/cloudwatchRoleArn,value=arn:aws:iam::123456789012:role/ApiGatewayCloudWatchLogs

Role đó cần trust policy cho apigateway.amazonaws.com và managed policy AmazonAPIGatewayPushToCloudWatchLogs.

Đây là thiết lập một lần cho cả tài khoản trong mỗi Region — quên nó thì bật logging ở mức method cũng không có log nào xuất hiện, và không có thông báo lỗi rõ ràng.

C — STS phải hoạt động ở Region đó. API Gateway assume role trên để ghi log, và việc assume role đi qua STS. Ở các Region cần bật thủ công (opt-in region như ap-east-1, me-south-1), nếu STS bị vô hiệu hoá thì API Gateway không assume được role và logging thất bại.

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

• A. "Log group hoặc stream chỉ xoá và tạo lại được bằng cách redeploy API" — sai. Log group của API Gateway là tài nguyên CloudWatch Logs thông thường — xoá và tạo lại được bằng CLI hoặc Console bất cứ lúc nào, không cần đụng tới API.
• B. "Trong access logging chỉ hỗ trợ biến $context và $input" — sai. Access logging chỉ hỗ trợ $context (và $util cho hàm tiện ích). $input chỉ dùng trong mapping template, không dùng được trong access log format.
• E. "Bị tính phí cho metric mức method và stage, nhưng không tính cho metric mức API" — nói ngược. Metric mức API là miễn phí; detailed metric ở mức method mới là thứ có tính phí (mỗi method sinh ra một bộ metric riêng).

Ghi nhớ

Hai loại logging của API Gateway — khác nhau hoàn toàn: | | Execution logging | Access logging | |---|---|---| | Nội dung | chi tiết xử lý nội bộ: request/response body, biến, lỗi | một dòng mỗi request, định dạng do bạn khai | | Mức | ERROR hoặc INFO | — | | Biến dùng được | — | chỉ $context | | Hợp cho | gỡ lỗi | phân tích, kiểm toán |

Danh sách kiểm khi bật logging mà không thấy log:

1. Account-level CloudWatch role đã cấu hình chưa? ← bước bị quên nhiều nhất
2. Log level đã bật ở stage settings chưa?
3. Đã redeploy stage sau khi đổi cấu hình chưa?
4. STS có hoạt động ở Region đó không?

Và cảnh báo: execution logging ở mức INFO ghi cả request/response body — có thể lộ dữ liệu nhạy cảm. Chỉ bật khi cần gỡ lỗi, và tắt ngay sau đó.

Đáp án

A và C.

• C — Stage variables — cho mỗi stage một giá trị cấu hình riêng.
• A — Lambda aliases — con trỏ có tên tới phiên bản hàm, cập nhật được theo thời gian.

Vì sao đúng

Yêu cầu: mỗi stage (prod, test, dev) trỏ tới một biến thể Lambda cập nhật được.

Hai tính năng ghép lại tạo thành mẫu chuẩn:

C — stage variable làm cầu nối giữa API Gateway và Lambda:

Integration URI: arn:aws:lambda:...:function:xu-ly:${stageVariables.alias}

Stage prod → alias = "prod"
Stage test → alias = "test"
Stage dev  → alias = "dev"

A — Lambda alias là thứ mà biến đó trỏ tới, và điểm mấu chốt là alias CẬP NHẬT ĐƯỢC:

aws lambda update-alias --function-name xu-ly --name prod --function-version 5

Đó chính là cụm "a Lambda function variant that can be updated over time" trong đề.

Kết quả: cấu hình API không bao giờ phải sửa — bạn chỉ trỏ alias sang version khác, và stage tương ứng tự dùng mã mới.

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

• B. Lambda Versions — đây là bẫy sát nhất, và điểm loại nằm ở một từ trong đề: version là BẤT BIẾN. Một khi publish, version 5 mãi mãi là version 5. Nó không "updated over time" được. Alias mới là thứ trỏ tới version và đổi được. (Version vẫn cần thiết — alias phải trỏ vào version — nhưng bản thân nó không đáp ứng yêu cầu "cập nhật được".)
• D. Mapping Templates — biến đổi định dạng request và response bằng VTL. Không liên quan tới việc chọn backend cho từng stage.
• E. Lambda X-Ray integration — công cụ theo dấu và phân tích hiệu năng. Không liên quan tới quản lý phiên bản hay stage.

Ghi nhớ

Mẫu thực hành tốt:

$LATEST  ← nơi phát triển
version 1, 2, 3, 4, 5  ← bất biến
alias "dev"   → $LATEST
alias "test"  → version 5
alias "prod"  → version 4

Lưu ý bắt buộc: khi integration dùng stage variable, API Gateway không tự thêm quyền vào resource-based policy của Lambda — phải tự thêm cho mọi alias có thể được gọi, nếu không API trả về lỗi 500 không nói gì.

Đáp án

D — Instance có thể thuộc một Auto Scaling group, nên một instance tương tự được tạo lại.

Vì sao đúng

Đây là hành vi cốt lõi của Auto Scaling: nó liên tục so số instance đang chạy với desired capacity và bù ngay khi thiếu.

Desired capacity: 3
Người dùng shutdown 1 instance  →  còn 2
ASG phát hiện thiếu             →  tạo instance MỚI từ launch template  →  về 3

Instance mới cùng loại, cùng AMI, cùng cấu hình — nên nhìn như thể "instance tự khởi động lại", đúng mô tả trong đề.

Muốn xoá thật thì phải làm đúng cách:

# Cách 1 — giảm desired capacity trước
aws autoscaling set-desired-capacity --auto-scaling-group-name nhom --desired-capacity 2

# Cách 2 — gỡ instance khỏi nhóm rồi mới huỷ
aws autoscaling detach-instances --instance-ids i-xxx \
  --auto-scaling-group-name nhom --should-decrement-desired-capacity

# Cách 3 — huỷ qua API của Auto Scaling (tự giảm desired)
aws autoscaling terminate-instance-in-auto-scaling-group \
  --instance-id i-xxx --should-decrement-desired-capacity

Một lưu ý nữa: shutdown từ bên trong hệ điều hành cũng khiến ASG coi instance là không lành và thay thế — nên đây là hành vi rất dễ gặp.

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

• A. "Instance thuộc Application Load Balancer nên tự khởi động lại" và C. "…Network Load Balancer…" — load balancer KHÔNG tạo hay khởi động instance. Nó chỉ phân phối traffic tới các target đã đăng ký, và ngừng gửi traffic tới target không lành. Việc tạo instance là của Auto Scaling.
• B. "Người dùng thiếu quyền, cần quyền root để terminate" — sai hai chỗ. Nếu thiếu quyền thì lệnh shutdown đã thất bại với UnauthorizedOperation, không phải thành công rồi có máy mới. Và "root permissions" không phải khái niệm của IAM — quyền được cấp bằng policy, không phải bằng vai trò root.

Ghi nhớ

Auto Scaling tạo instance mới trong ba tình huống: | Tình huống | Nguyên nhân | |---|---| | Số instance < desired | ai đó huỷ hoặc dừng instance | | Instance bị đánh dấu unhealthy | status check hỏng, hoặc ELB health check hỏng (nếu HealthCheckType: ELB) | | Scaling policy kích hoạt | metric vượt ngưỡng |

Và hai cơ chế bảo vệ instance khỏi bị ASG huỷ: | Cơ chế | Chống | |---|---| | Instance scale-in protection | ASG huỷ khi scale-in | | Lifecycle hook (terminating) | giữ lại ở Terminating:Wait để gỡ lỗi |

Lưu ý quan trọng: DisableApiTermination (termination protection của EC2) KHÔNG ngăn được Auto Scaling — đó là nguồn của nhiều sự cố "tôi đã bật bảo vệ mà máy vẫn bị xoá".

Đáp án

A — Amazon EFS Standard–IA storage class.

Vì sao đúng

Đề nêu bốn yêu cầu, và chúng cùng nhau chỉ về đúng một lựa chọn:

EFS là lựa chọn duy nhất trong bốn phương án cho phép hàng trăm instance mount cùng lúc qua NFS — mỗi máy đọc ghi như thư mục cục bộ.

Standard–IA giảm mạnh chi phí lưu trữ, đổi lại là phí truy xuất mỗi lần đọc. Với dữ liệu ít được dùng, tổng chi phí thấp hơn nhiều.

Và có một tính năng nên bật kèm: EFS Lifecycle Management tự chuyển tệp không được truy cập trong N ngày (7, 14, 30, 60, 90) sang IA, rồi tự chuyển ngược lại khi có người đọc.

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

• C. EFS Standard storage class — đúng dịch vụ nhưng sai lớp lưu trữ: Standard đắt hơn nhiều và dành cho dữ liệu được truy cập thường xuyên. Đề nói rõ là "less frequently accessed".
• B. Amazon EBS — EBS volume chỉ gắn được vào MỘT instance trong MỘT AZ (trừ Multi-Attach với io1/io2, và cũng chỉ trong cùng AZ, tối đa 16 instance). Không thể cho hàng trăm máy dùng chung.
• D. S3 Standard-IA — rẻ và bền, nhưng S3 là kho object, không phải hệ thống tệp: không mount được, không có đường dẫn POSIX, không có khoá tệp. Ứng dụng phải sửa mã để gọi API S3 — mà đề mô tả nhu cầu file storage cho nhiều instance.

Ghi nhớ

Chọn lưu trữ theo nhu cầu: | Nhu cầu | Dịch vụ | |---|---| | Hệ thống tệp POSIX, nhiều instance mount | EFS | | Ổ đĩa khối cho một instance | EBS | | Kho object, truy cập qua API | S3 | | Chia sẻ cho Windows/SMB | FSx for Windows | | HPC, tích hợp S3 | FSx for Lustre |

Các lớp lưu trữ của EFS: | Lớp | Dùng cho | |---|---| | Standard | truy cập thường xuyên, đa AZ | | Standard–IA | ít truy cập, đa AZ | | One Zone | thường xuyên, một AZ — rẻ hơn | | One Zone–IA | rẻ nhất — ít truy cập, một AZ |

Nếu dữ liệu chấp nhận được rủi ro mất khi một AZ hỏng, One Zone–IA còn rẻ hơn nữa — nhưng đề không nêu điều kiện đó.

Đáp án

D — Dùng launch template cho Auto Scaling group với cả On-Demand lẫn Spot, và dùng trường User data để cài CodeDeploy agent.

Vì sao đúng

Đề có hai yêu cầu, và launch template đáp ứng cả hai — trong khi launch configuration thì không:

Yêu cầu 1 — trộn On-Demand và Spot. Đây là điểm loại quyết định:

"MixedInstancesPolicy": {
  "LaunchTemplate": {"LaunchTemplateSpecification": {"LaunchTemplateId": "lt-xxx"}},
  "InstancesDistribution": {
    "OnDemandBaseCapacity": 2,
    "OnDemandPercentageAboveBaseCapacity": 25,
    "SpotAllocationStrategy": "capacity-optimized"
  }
}

Yêu cầu 2 — tự cài CodeDeploy agent. User data chạy lúc boot lần đầu:

#!/bin/bash
yum update -y
yum install -y ruby wget
cd /home/ec2-user
wget https://aws-codedeploy-ap-southeast-1.s3.amazonaws.com/latest/install
chmod +x ./install && ./install auto

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

• A. Dùng launch configuration — không hỗ trợ mixed instances policy, nên không trộn được On-Demand và Spot. Đây là điểm loại tuyệt đối. Launch configuration cũng đã bị AWS ngừng phát triển.
• B. Dùng AWS Systems Manager để cài và cập nhật CodeDeploy agent — đây là phương án hợp lý một phần và cần phân biệt: SSM có cài được agent (qua State Manager association với document AWS-ConfigureAWSPackage), và đó là cách tốt để giữ agent luôn cập nhật. Nhưng nó không giải quyết vế mixed instances policy — mà đó mới là yêu cầu khó hơn.
• C. "AWS Resource Access Manager (RAM) lên lịch cài agent" — hoàn toàn sai chức năng. RAM dùng để chia sẻ tài nguyên giữa các tài khoản AWS (subnet, transit gateway, license). Nó không cài phần mềm và không có lịch nào.

Ghi nhớ

Bảng so sánh cần thuộc: | | Launch configuration | Launch template | |---|---|---| | Phiên bản hoá | ❌ | ✅ | | Sửa được | không — tạo cái mới | tạo version mới | | Mixed instances, Spot | ❌ | ✅ | | Nhiều network interface, placement group nâng cao | ❌ | ✅ | | Trạng thái | ngừng phát triển | khuyến nghị |

Với thiết kế mới, luôn dùng launch template — không có lý do nào để dùng launch configuration nữa.

Và mẹo thực dụng: nên kết hợp cả hai cách cài agent — user data cho lần đầu, SSM State Manager để giữ agent luôn cập nhật về sau.

Đáp án

A — HTTP 503.

Vì sao đúng

503 Service Unavailable là mã ALB trả về khi không có target lành nào để chuyển request tới:

Ý nghĩa của mã này rất chính xác: "máy chủ hiện không thể xử lý request" — ALB hoạt động bình thường, nó chỉ không có ai để chuyển tiếp.

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

Ba mã còn lại đều là lỗi thật của ALB nhưng cho nguyên nhân khác hẳn — và phân biệt được chúng là kỹ năng chẩn đoán rất thực dụng:

• D. 504 Gateway Timeout — target nhận được request nhưng không trả lời kịp trong idle timeout của ALB (mặc định 60 giây). Thường do truy vấn CSDL chậm hoặc ứng dụng treo.
• B. 500 Internal Server Error — thường do chính ứng dụng sinh ra, hoặc ALB gặp lỗi nội bộ.
• C. 403 Forbidden — do WAF chặn, hoặc chính ứng dụng từ chối. Không liên quan tới việc thiếu target.

Ghi nhớ

Bảng chẩn đoán ALB theo mã lỗi — đáng thuộc: | Mã | Nghĩa | Kiểm tra gì | |---|---|---| | 503 | không có target lành | target đã đăng ký chưa? health check qua chưa? | | 502 | target trả về phản hồi hỏng | ứng dụng crash? chứng chỉ target không hợp lệ? | | 504 | target trả lời quá chậm | truy vấn chậm? tăng idle timeout? | | 500 | lỗi trong ứng dụng hoặc ALB | log ứng dụng | | 400 | request từ client không hợp lệ | — | | 401/403 | xác thực/uỷ quyền thất bại | authorizer, WAF |

Danh sách kiểm cho 503, theo thứ tự:

1. Listener có rule trỏ vào target group không?
2. Target group có target nào không?
3. Target ở trạng thái healthy không? (xem Health status details để biết lý do)
4. Security group của instance có cho phép SG của ALB không?
5. Đường dẫn và cổng health check có đúng không?