TL;DR
Bạn đang gặp lỗi An error occurred (NoSuchBucket) when calling the operation vì một trong ba nguyên nhân: tên bucket sai, bucket nằm ở region AWS khác với bạn nghĩ, hoặc bucket đã bị xóa. Hãy kiểm tra tên trước, rồi đến region.
# Bucket có thực sự tồn tại không?
aws s3 ls s3://your-bucket-name
# Nếu lệnh trên thất bại, tìm xem bucket đang ở đâu
aws s3api get-bucket-location --bucket your-bucket-name
Nguyên nhân gốc rễ
Tên S3 bucket là duy nhất trên toàn cầu — nhưng bản thân các bucket lại mang tính khu vực. Khi AWS ném lỗi NoSuchBucket, nghĩa là nó không thể tìm thấy bucket bạn đang trỏ đến ở region mà client của bạn đang nhắm tới. Bucket có thể không tồn tại, hoặc SDK của bạn đang giao tiếp với endpoint region sai.
Lỗi này xuất hiện dưới nhiều dạng khác nhau tùy theo thao tác:
An error occurred (NoSuchBucket) when calling the PutObject operation: The specified bucket does not exist
An error occurred (NoSuchBucket) when calling the GetObject operation: The specified bucket does not exist
An error occurred (NoSuchBucket) when calling the ListObjectsV2 operation: The specified bucket does not exist
Năm nguyên nhân phổ biến chiếm khoảng 95% các trường hợp:
- Sai region — bucket ở
ap-southeast-1nhưng client của bạn đang nhắm tớius-east-1 - Gõ sai tên bucket — tên phân biệt chữ hoa/thường, chỉ dùng dấu gạch ngang (không dùng gạch dưới)
- Bucket đã bị xóa — ai đó đã chạy
terraform destroy, hoặc một đồng nghiệp dọn dẹp nhầm môi trường - Sai AWS account — bạn đang xác thực vào staging nhưng bucket lại nằm ở production
- Biến môi trường cũ —
BUCKET_NAMEvẫn đang trỏ đến bucket cũ từ quý trước
Cách sửa từng bước
Bước 1 — Xác minh bucket có tồn tại không
# Liệt kê tất cả bucket trong account
aws s3 ls
# Kiểm tra xem bucket cụ thể này có trong danh sách không
aws s3 ls s3://your-bucket-name 2>&& echo "EXISTS" || echo "NOT FOUND"
Nếu bucket của bạn không xuất hiện trong kết quả aws s3 ls, thì nó đã bị xóa hoặc đang nằm ở một account khác.
Bước 2 — Tìm region thực tế của bucket
aws s3api get-bucket-location --bucket your-bucket-name
Ví dụ kết quả trả về:
{
"LocationConstraint": "ap-southeast-1"
}
Giá trị null có nghĩa là bucket đang ở us-east-1 — đó là cách AWS biểu diễn region này. Hãy đảm bảo SDK hoặc CLI của bạn khớp chính xác với region này.
Bước 3 — Sửa region trong AWS CLI
# Truyền region trực tiếp cho từng lệnh
aws s3 cp file.txt s3://your-bucket-name/ --region ap-southeast-1
# Hoặc cố định cho toàn bộ phiên làm việc
export AWS_DEFAULT_REGION=ap-southeast-1
Bước 4 — Sửa region trong boto3 (Python)
import boto3
# Khai báo region rõ ràng — đừng phụ thuộc vào giá trị mặc định từ môi trường trong production
s3 = boto3.client('s3', region_name='ap-southeast-1')
try:
s3.put_object(Bucket='your-bucket-name', Key='test.txt', Body=b'hello')
except s3.exceptions.NoSuchBucket as e:
print(f"Bucket not found: {e}")
except Exception as e:
print(f"Other error: {e}")
Bước 5 — Sửa region trong AWS SDK cho Node.js
const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3');
// Khai báo region rõ ràng — đừng để SDK tự phát hiện trong trường hợp này
const s3 = new S3Client({ region: 'ap-southeast-1' });
try {
await s3.send(new PutObjectCommand({
Bucket: 'your-bucket-name',
Key: 'test.txt',
Body: 'hello',
}));
} catch (err) {
if (err.name === 'NoSuchBucket') {
console.error('Bucket not found — check name and region');
}
}
Bước 6 — Tạo lại bucket nếu đã bị xóa
# Tạo bucket ở region cụ thể (bắt buộc với các region ngoài us-east-1)
aws s3api create-bucket \
--bucket your-bucket-name \
--region ap-southeast-1 \
--create-bucket-configuration LocationConstraint=ap-southeast-1
# us-east-1 là ngoại lệ — bỏ qua LocationConstraint
aws s3api create-bucket --bucket your-bucket-name --region us-east-1
Lưu ý: nếu một AWS account khác đã sở hữu tên bucket đó trên toàn cầu, bạn sẽ nhận lỗi BucketAlreadyExists. Hãy chọn tên khác — không có cách nào vượt qua tính duy nhất toàn cầu này.
Bước 7 — Xác nhận bạn đang ở đúng account
aws sts get-caller-identity
Kết quả trả về:
{
"UserId": "AIDA...",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/your-user"
}
Số account sai? Hãy chuyển profile và kiểm tra lại:
export AWS_PROFILE=production
aws sts get-caller-identity
Bước 8 — Tìm kiếm các biến môi trường cũ
# Kiểm tra shell của bạn đang nhận diện bucket là gì
echo $AWS_DEFAULT_REGION
echo $BUCKET_NAME
echo $S3_BUCKET
# Đang chạy trong Docker? Kiểm tra bên trong container
docker exec your-container env | grep -i bucket
docker exec your-container env | grep -i aws
Các biến môi trường cũ trỏ đến bucket đã bị xóa hoặc đổi tên gây ra nhiều sự cố production hơn người ta thường thừa nhận. Một lần deploy từ sáu tháng trước âm thầm gán BUCKET_NAME=myapp-prod-old và không ai phát hiện cho đến 2 giờ sáng.
Xác minh
Chạy kiểm tra toàn bộ vòng lặp đọc/ghi trước khi đóng sự cố:
# Ghi một object thử nghiệm
echo "test" | aws s3 cp - s3://your-bucket-name/healthcheck.txt --region ap-southeast-1
# Đọc lại
aws s3 cp s3://your-bucket-name/healthcheck.txt - --region ap-southeast-1
# Dọn dẹp
aws s3 rm s3://your-bucket-name/healthcheck.txt
Cả ba lệnh đều thành công không có lỗi? Bucket của bạn đã truy cập được và cấu hình đã ổn.
Biện pháp phòng ngừa
- Khai báo cứng region trong mọi SDK client — tự phát hiện tự động ổn khi phát triển cục bộ, nhưng không nên dùng trong production
- Lưu tên bucket trong SSM Parameter Store hoặc Secrets Manager thay vì hardcode — tránh lỗi đánh máy và giúp việc thay đổi dễ dàng hơn
- Thêm bước kiểm tra sự tồn tại của bucket vào quá trình khởi động ứng dụng hoặc endpoint health check, để cấu hình sai bị phát hiện ngay lúc khởi động, không phải giữa chừng khi đang xử lý request
- Bật S3 Versioning và MFA Delete cho các bucket quan trọng — một lần chạy nhầm
terraform destroysẽ không xóa vĩnh viễn dữ liệu của bạn - Gắn tag cho mọi bucket với
Environment(prod/staging) vàTeam— khi bạn đang xử lý sự cố lúc nửa đêm, các tag này tiết kiệm rất nhiều thời gian thực tế