Bài đăng

Hiểu Rõ Burstable T3 Instances: CPU Credits Là Gì Và Tại Sao Server Đột Ngột Chậm Lại?

Bạn đang chạy một EC2 T3 instance, mọi thứ hoạt động bình thường, rồi đột nhiên sau một đợt tải cao kéo dài vài giờ, server bắt đầu phản hồi chậm như đang bò — CPU usage nhìn vào chỉ còn 5-10% nhưng latency tăng vọt. Đây không phải lỗi ứng dụng, không phải network issue. Đây là cơ chế CPU Credits của burstable T3 instances đang hoạt động đúng như thiết kế, và nếu bạn chưa hiểu nó, bạn sẽ mất hàng giờ debug sai hướng. TL;DR — Tóm Tắt Nhanh Khái niệm Giải thích ngắn CPU Credit Đơn vị tích lũy cho phép T3 instance burst vượt baseline CPU Baseline CPU Mức CPU được phân bổ liên tục, tùy theo loại instance (ví dụ: t3.micro = 10%) Credit tích lũy Khi CPU dùng dưới baseline, credits được tích lũy theo thời gian Credit tiêu hao Khi CPU vượt baseline, credits bị tiêu thụ để duy trì hiệu năng Credit cạn kiệt Instance bị throttle về đúng mức baseline — đây là lý do server chậm đột ngột Unlimited mode Cho p...
Đăng nhận xét
Đọc thêm

Khôi Phục File S3 Đã Xóa: Hướng Dẫn Thực Tế Khi Bật Versioning

Bạn vừa chạy lệnh aws s3 rm và nhận ra mình vừa xóa nhầm file quan trọng trên S3 — cảm giác đó không dễ chịu chút nào. Tin tốt là nếu bucket đã bật S3 Versioning , file đó chưa thực sự mất: AWS chỉ tạo một 'delete marker' che đi object gốc, toàn bộ các version trước vẫn còn nguyên trong hệ thống. TL;DR — Khôi Phục File S3 Đã Xóa Nhanh Bước Hành động Mục đích 1 Xác nhận Versioning đang bật Đảm bảo version history tồn tại 2 Liệt kê tất cả versions của object Tìm version ID cần khôi phục 3 Xác định delete marker Hiểu tại sao object 'biến mất' 4 Xóa delete marker Khôi phục object về trạng thái hiện hành 5 Xác nhận object đã trở lại Kiểm tra kết quả S3 Versioning Hoạt Động Như Thế Nào Khi Xóa File Trước khi bắt tay vào khôi phục, cần hiểu đúng cơ chế — vì đây là điểm mà nhiều người hiểu sai và làm mất thêm data. Khi Versioning được bật và bạn thực hiện DELETE một object mà không ...
Đăng nhận xét
Đọc thêm

Lambda Kết Nối RDS Private Subnet: Cấu Hình VPC, Subnet và Security Group

Lambda không thể kết nối được RDS trong private subnet là một trong những lỗi phổ biến nhất khi mới bắt đầu làm việc với kiến trúc serverless — và cũng là lỗi dễ mất nhiều giờ nhất vì nó thường không trả về thông báo lỗi rõ ràng, chỉ là timeout. Bài viết này giải thích cơ chế hoạt động, lý do tại sao cần cấu hình VPC cho Lambda khi kết nối RDS private subnet, và từng bước cấu hình chính xác. TL;DR — Lambda Kết Nối RDS Private Subnet Vấn đề Nguyên nhân Giải pháp Lambda timeout khi kết nối RDS Lambda chạy ngoài VPC, không thể reach private subnet Gắn Lambda vào VPC, đúng subnet và Security Group Lambda trong VPC mất internet Private subnet không có NAT Gateway Dùng VPC Endpoint hoặc thêm NAT Gateway Vẫn timeout dù đã cấu hình VPC Security Group inbound rule thiếu hoặc sai port Cho phép inbound từ Lambda SG đến RDS SG trên port DB RDS không nhận kết nối RDS Security Group chưa có rule cho Lambda Thêm inbound...
Đăng nhận xét
Đọc thêm

Khi Nào Nên Dùng ElastiCache Redis: Giải Quyết RDS Chậm Do Query Lặp Lại

Bạn đang nhìn vào dashboard CloudWatch và thấy RDS read latency tăng dần — không phải vì dữ liệu phức tạp hơn, mà vì cùng một câu query chạy đi chạy lại hàng trăm lần mỗi phút. Đây là dấu hiệu kinh điển cần thêm một lớp caching, và ElastiCache Redis là lựa chọn phổ biến nhất trong hệ sinh thái AWS để giải quyết bài toán này. TL;DR — ElastiCache Redis Giải Quyết Vấn Đề Gì Vấn đề Nguyên nhân gốc Giải pháp với Redis RDS latency cao Cùng query chạy lặp lại, đánh vào disk/buffer pool Cache kết quả query, trả về từ RAM RDS CPU spike Nhiều connection đồng thời, query phức tạp Giảm số lượng query thực sự chạm RDS Read replica không đủ Scale read replica tốn chi phí, vẫn là DB round-trip Cache hit không cần round-trip DB Session/token lookup chậm Mỗi request đều query DB để validate Lưu session trong Redis, sub-millisecond lookup Cách ElastiCache Redis Hoạt Động Trong Kiến Trúc AWS Redis là in-memory data ...
Đăng nhận xét
Đọc thêm

LSI vs GSI trong DynamoDB: Khi Nào Dùng Index Nào?

Bạn đã thiết kế xong bảng DynamoDB với primary key hoàn hảo, rồi product manager yêu cầu thêm một màn hình tìm kiếm theo thuộc tính hoàn toàn khác — đây là lúc Local Secondary Index và Global Secondary Index xuất hiện, và cũng là lúc nhiều team chọn sai loại index rồi phải migration đau đớn sau này. TL;DR: LSI vs GSI trong DynamoDB Tiêu chí LSI (Local Secondary Index) GSI (Global Secondary Index) Partition key Giống bảng gốc Có thể khác hoàn toàn Sort key Khác bảng gốc (bắt buộc) Tùy chọn Tạo sau khi bảng tồn tại Không — chỉ khi tạo bảng Có — bất kỳ lúc nào Tính nhất quán đọc Strongly consistent hoặc eventually consistent Chỉ eventually consistent Giới hạn storage per partition 10 GB per partition key value Không giới hạn theo partition Throughput Dùng chung với bảng gốc Throughput độc lập (provisioned) hoặc on-demand Số lượng tối đa 5 per table 20 per table (soft limit) Cơ Chế Hoạt Đ...
Đăng nhận xét
Đọc thêm

Sử Dụng IAM Groups: Gán Policy Trực Tiếp Cho User Hay Dùng Group?

Bạn vừa onboard một developer mới và cần cấp quyền truy cập S3, CodeCommit, CloudWatch. Gán thẳng policy vào user cho nhanh — ai cũng từng làm vậy. Sáu tháng sau, team có 15 người, mỗi người một mớ policy gắn trực tiếp, và không ai còn biết chắc ai đang có quyền gì. Đây là vấn đề cốt lõi mà IAM Groups được thiết kế để giải quyết. TL;DR — IAM Groups vs. Gán Policy Trực Tiếp Tiêu chí Gán Policy Trực Tiếp (User) IAM Group Quản lý quyền theo vai trò Thủ công, lặp lại Tập trung, nhất quán Onboard/offboard user Phải gán/xóa từng policy Thêm/xóa user khỏi group Audit quyền truy cập Phải kiểm tra từng user Kiểm tra policy tại group Rủi ro cấu hình sai Cao — dễ bỏ sót hoặc thừa quyền Thấp hơn — policy dùng chung Giới hạn policies per entity 10 managed policies per user 10 managed policies per group Phù hợp với Well-Architected Không khuyến nghị Được khuyến nghị IAM Groups Hoạt Động Như Thế Nào IA...
Đăng nhận xét
Đọc thêm