Tình huống
Đây là một tình huống gây ức chế kinh điển trên AWS. Bạn đã kiểm tra Lambda function trong console và nó trả về kết quả 200 OK hoàn hảo. Mọi thứ trông có vẻ đã sẵn sàng. Nhưng ngay khi bạn kích hoạt endpoint API Gateway qua Postman hoặc frontend, yêu cầu lại gặp lỗi 500 Internal Server Error.
Khi bạn kiểm tra API Gateway Execution Logs trong CloudWatch, bạn sẽ tìm thấy nguyên nhân:
Execution failed due to configuration error: Invalid permissions on Lambda function
Lỗi này thường có nghĩa là API Gateway đang "gõ cửa", nhưng Lambda không cho phép vào. Ngay cả khi Lambda của bạn có một IAM Role với quyền AdministratorAccess, điều đó chỉ xác định những gì Lambda có thể làm với các dịch vụ khác. Bạn đang thiếu Resource-based Policy, thứ xác định ai được phép kích hoạt Lambda ngay từ đầu.
Cách gỡ lỗi thiếu hụt quyền hạn
Trước khi thay đổi bất cứ điều gì, hãy xác minh xem policy có tồn tại hay không. Chạy lệnh này trong terminal của bạn:
aws lambda get-policy --function-name your-function-name
Hãy nhìn vào kết quả đầu ra. Nếu bạn thấy ResourceNotFoundException hoặc nếu trường Principal thiếu apigateway.amazonaws.com, kết nối đã bị chặn. API Gateway đơn giản là không có "thư mời" để tham gia bữa tiệc.
Giải pháp
Cách 1: Sử dụng AWS CLI (Cách nhanh nhất)
Bạn có thể cấp quyền thủ công bằng một câu lệnh duy nhất. Đây thường là cách khắc phục nhanh nhất cho môi trường phát triển (dev) bị lỗi. Hãy thay thế các trình giữ chỗ bằng thông tin chi tiết của bạn, chẳng hạn như us-east-1 và ID tài khoản AWS gồm 12 chữ số của bạn:
aws lambda add-permission \
--function-name your-function-name \
--statement-id AllowAPIGatewayInvoke \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn "arn:aws:execute-api:us-east-1:123456789012:api-id/*/*/*"
Hậu tố */*/* là một ký tự đại diện (wildcard). Nó cho phép bất kỳ stage nào (như prod hoặc dev), bất kỳ phương thức HTTP nào (GET, POST) và bất kỳ đường dẫn tài nguyên nào trong API đó kích hoạt function của bạn.
Cách 2: Sử dụng AWS Console
- Mở Lambda Console và chọn function của bạn.
- Chuyển đến tab Configuration và chọn Permissions.
- Tìm phần Resource-based policy statements và nhấp vào Add permissions.
- Chọn AWS Service và chọn API Gateway từ danh sách thả xuống.
- Gán một Statement ID (ví dụ:
ProdApiAccess). - Đặt Principal thành
apigateway.amazonaws.com. - Giới hạn quyền truy cập bằng cách dán ARN của API Gateway vào trường Source ARN. Điều này ngăn các API khác trong tài khoản của bạn vô tình kích hoạt function này.
- Nhấp vào Save.
Cách 3: Infrastructure as Code (Terraform)
Các bản sửa lỗi thủ công trong console rất dễ bị quên trong lần triển khai tiếp theo. Nếu bạn sử dụng Terraform, hãy đảm bảo bạn bao gồm tài nguyên aws_lambda_permission. Đây là mắt xích còn thiếu kết nối API với Lambda của bạn.
resource "aws_lambda_permission" "apigw_lambda" {
statement_id = "AllowExecutionFromAPIGateway"
action = "lambda:InvokeFunction"
function_name = aws_lambda_function.my_lambda.function_name
principal = "apigateway.amazonaws.com"
# ARN này cho phép bất kỳ phương thức nào trên bất kỳ đường dẫn nào trong API
source_arn = "${aws_api_gateway_rest_api.my_api.execution_arn}/*/*"
}
Xác minh
Sau khi áp dụng bản sửa lỗi, hãy quay lại console API Gateway để kiểm tra tích hợp:
- Chọn API của bạn, sau đó chọn Resource và Method cụ thể.
- Nhấp vào tab Test (biểu tượng hình tia chớp).
- Nhấn nút Test.
Kết quả thành công giờ đây sẽ khác. Thay vì lỗi cấu hình, log của bạn sẽ hiển thị Endpoint response body before transformations theo sau là kết quả đầu ra thực tế của Lambda.
Bài học rút ra
AWS Console đôi khi gây hiểu lầm. Khi bạn liên kết Lambda với API Gateway một cách thủ công, giao diện người dùng thường tự động thêm các quyền này ở chế độ nền với một thông báo xác nhận nhỏ. Tuy nhiên, khi bạn sử dụng CLI, SAM hoặc Terraform, "phép màu" đó không xảy ra. Bạn phải chịu trách nhiệm cho mọi mắt xích trong chuỗi liên kết.
Bạn đang gặp khó khăn với định dạng YAML khi thêm các quyền này vào template SAM? Tôi thường sử dụng Bộ chuyển đổi YAML ↔ JSON trên ToolCraft để phát hiện lỗi thụt đầu dòng. Nó nhanh hơn việc phải chờ năm phút để một CloudFormation stack rollback chỉ vì một khoảng trắng đặt sai chỗ.
Điểm mấu chốt: IAM Roles kiểm soát những gì Lambda làm. Resource-based policies kiểm soát ai có thể gọi nó. Hãy phân biệt rõ hai khái niệm này, và bạn sẽ tiết kiệm được hàng giờ đồng hồ gỡ lỗi.