SW BBANG V

Bạn vừa upload file mới lên S3, reload trang và vẫn thấy phiên bản cũ — đây là tình huống kinh điển khi làm việc với CloudFront. Cache tại edge location chưa hết TTL, nên CloudFront tiếp tục phục vụ object cũ từ bộ nhớ đệm mà không hề biết S3 đã thay đổi. Giải pháp trực tiếp nhất là tạo một CloudFront Invalidation để buộc các edge node xóa bản cache và fetch lại từ origin. TL;DR — Cập Nhật Nội Dung CloudFront Nhanh Bước Hành động Kết quả 1 Upload file mới lên S3 Origin đã có nội dung mới 2 Tạo Invalidation trên distribution Edge cache bị xóa 3 Chờ invalidation hoàn tất (~1-5 phút) Request tiếp theo fetch từ S3 4 Xác minh bằng curl hoặc browser Nội dung mới được phục vụ CloudFront Cache Hoạt Động Như Thế Nào CloudFront duy trì một mạng lưới edge location toàn cầu. Khi người dùng request một object, CloudFront kiểm tra cache tại edge gần nhất. Nếu object đã được cache và chưa hết TTL, CloudFront trả...

Bạn vừa tích hợp xong Amazon SES, gửi thử email cho chính mình thì nhận được ngay — nhưng khi deploy lên production, toàn bộ email gửi cho khách hàng đều bị từ chối với lỗi MessageRejected . Đây là triệu chứng điển hình của SES Sandbox Mode, và nếu bạn không biết mình đang ở trong đó, bạn sẽ mất hàng giờ debug ở tầng application trong khi vấn đề nằm ở tầng account. TL;DR — SES Sandbox Mode Là Gì Và Cần Làm Gì Vấn đề Nguyên nhân Giải pháp Chỉ gửi được cho email đã verify Account đang ở Sandbox Mode Request production access qua SES console Bị giới hạn 200 email/ngày Sandbox sending quota Yêu cầu tăng sending limit trong cùng request Lỗi MessageRejected Địa chỉ đích chưa được verify Verify địa chỉ đích hoặc thoát Sandbox Không thấy nút request production access Sai region trong console Kiểm tra đúng region đang dùng SES SES Sandbox Mode Hoạt Động Như Thế Nào Mọi AWS account khi bắt đầu sử dụng SES đề...

Bạn vừa launch một EC2 instance mới và muốn Nginx được cài đặt sẵn ngay khi máy chủ khởi động lần đầu — không cần SSH vào tay, không cần chạy lệnh thủ công. Đây là bài toán cực kỳ phổ biến trong production, và EC2 User Data chính là cơ chế giải quyết nó một cách sạch sẽ nhất. TL;DR — Tóm Tắt Nhanh Bước Hành động Lưu ý quan trọng 1 Soạn shell script cài Nginx Dòng đầu phải là #!/bin/bash 2 Dán vào ô 'User Data' khi launch instance EC2 Console → Advanced Details → User Data 3 Script chạy một lần duy nhất lúc first boot Chạy với quyền root, không cần sudo 4 Kiểm tra log tại /var/log/cloud-init-output.log Đây là nơi debug khi script không chạy đúng EC2 User Data Hoạt Động Như Thế Nào Trước khi paste script vào console, cần hiểu đúng cơ chế để tránh những lỗi ngớ ngẩn mà ai cũng từng gặp ít nhất một lần. Khi một EC2 instance khởi động, dịch vụ cloud-init chạy rất sớm trong quá trình boot — tr...

Bạn vừa tạo xong một SNS topic, gắn subscription email, deploy xong Lambda hoặc CloudWatch Alarm — rồi ngồi chờ. Không có gì. Đây là lỗi cực kỳ phổ biến khi mới làm việc với Amazon SNS email alert : subscription ở trạng thái PendingConfirmation và AWS đã gửi một email xác nhận đến inbox của bạn, nhưng bạn chưa click vào link đó. TL;DR — Tóm Tắt Nhanh Vấn đề Nguyên nhân Hành động Không nhận được email alert Subscription chưa được xác nhận Kiểm tra inbox, click link xác nhận Email xác nhận không đến Sai địa chỉ email hoặc bị spam filter Kiểm tra spam/junk, tạo lại subscription Subscription vẫn Pending sau 3 ngày Token xác nhận đã hết hạn Xóa subscription cũ, tạo mới Đã confirm nhưng vẫn không nhận Topic policy hoặc IAM chặn publish Kiểm tra resource policy của topic Amazon SNS Email Subscription Hoạt Động Như Thế Nào SNS không gửi email trực tiếp ngay khi bạn tạo subscription. Thay vào đó, nó thực h...

Bạn vừa được yêu cầu bật mã hóa cho S3 bucket chứa dữ liệu nhạy cảm. Console hiện ra ba lựa chọn: SSE-S3, SSE-KMS với AWS Managed Key, SSE-KMS với Customer Managed Key. Câu hỏi thực tế không phải là 'mã hóa có cần thiết không' mà là 'chọn loại key nào, và cái đó sẽ tốn bao nhiêu tiền mỗi tháng khi traffic tăng lên.' TL;DR — AWS KMS Key Types cho S3 Tiêu chí AWS Managed Key (aws/s3) Customer Managed Key (CMK) Ai quản lý key? AWS tự động quản lý Bạn tự tạo và quản lý Phí lưu trữ key Miễn phí ~$1/tháng/key Phí API call Miễn phí (không tính phí API) $0.03 / 10,000 requests Key rotation Tự động hàng năm, không tắt được Tùy chọn, có thể bật/tắt Key policy tùy chỉnh Không Có Cross-account access Không hỗ trợ Có h...

Một trong những câu hỏi hay gặp nhất khi thiết kế hệ thống trên AWS là: bật Multi-AZ cho RDS có giúp tăng hiệu năng đọc không, hay nó chỉ phục vụ mục đích failover? Câu trả lời ngắn gọn là: Multi-AZ không cải thiện hiệu năng đọc — nhưng nếu bạn đang vận hành hệ thống production mà thiếu nó, bạn đang chấp nhận một rủi ro downtime không cần thiết. TL;DR — RDS Multi-AZ là gì và có lợi ích gì? Multi-AZ là cơ chế high availability của RDS, không phải cơ chế scale-out. Bảng dưới tóm tắt những điểm quan trọng nhất: Khía cạnh Multi-AZ Read Replica Mục đích chính High availability, failover tự động Scale-out đọc, giảm tải primary Standby có nhận traffic đọc không? Không (với Multi-AZ DB Instance) Có Replication Synchronous Asynchronous Failover tự động Có Không (thủ công) RTO mục tiêu Thường dưới 2 phút (tùy engine) Không áp dụng Ảnh hưởng hiệu năng ghi Có thể tăng nhẹ latency do sync replication Không...