Bài đăng

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 ...

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...

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 ...

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 Đ...

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...

NAT Gateway vs NAT Instance: Chọn Giải Pháp Nào Cho Private Subnet Trên AWS?

Bạn vừa dựng xong một private subnet, các EC2 instance bên trong cần tải bản cập nhật từ internet nhưng không được phép nhận kết nối từ bên ngoài vào — đây là bài toán NAT cổ điển trên AWS. Câu hỏi thực tế là: dùng NAT Gateway được quản lý hoàn toàn bởi AWS, hay tự vận hành một EC2 instance làm NAT? Câu trả lời không đơn giản là 'dùng cái nào rẻ hơn' — nó phụ thuộc vào yêu cầu vận hành, khả năng kiểm soát traffic, và ngân sách thực tế của bạn. TL;DR — NAT Gateway vs NAT Instance Tiêu chí NAT Gateway NAT Instance Quản lý hạ tầng AWS quản lý hoàn toàn Bạn tự quản lý EC2 Tính sẵn sàng cao Tích hợp sẵn trong một AZ Phải tự thiết kế HA Băng thông Scale tự động (xem AWS docs) Giới hạn bởi instance type Security Group Không áp dụng trực tiếp Áp dụng đầy đủ Port forwarding Không hỗ trợ Hỗ trợ qua iptables Chi phí Tính theo giờ + data processed Tính theo EC2 instance type Phù hợp nhất Produc...