AWS Quá Phức Tạp? 5 Lý Do Developer Đang Rời Bỏ — Và Lời Khuyên Thực Tế
Khi Người Dùng AWS Trung Thành Nhất Cũng Phản Tỉnh
Tuần rồi, một bài viết trên Hacker News thu hút hàng trăm bình luận chỉ trong vài giờ: "I returned to AWS and was reminded why I left" — của một developer đã dùng AWS suốt 15 năm, từ thời SQS, S3, EC2 còn sơ khai.
Điều đáng nói: đây không phải anti-AWS rant từ người mới. Đây là lời chia tay từ một người đã tổ chức sự kiện AWS đầu tiên tại Melbourne, đã uống "Kool-Aid" đến giọt cuối cùng.
Và anh ta không đơn lẻ. Phần lớn comment trên HN đều đồng tình.
Với kinh nghiệm quản lý team NodeJS chạy trên AWS nhiều năm, bài viết này muốn phân tích nguyên nhân thật sự đằng sau làn sóng này — và quan trọng hơn, bạn nên làm gì.
5 Vấn Đề Cốt Lõi Của AWS
1. IAM — "Lucifer Thiết Kế Hệ Thống Phân Quyền"
Đây là phàn nàn phổ biến nhất. IAM (Identity and Access Management) đáng lẽ đơn giản — ai được phép làm gì — nhưng thực tế lại là mê cung policy, role, trust relationship, condition key.
Một ví dụ thực tế: muốn cho Lambda function đọc S3 bucket, bạn cần:
- IAM role cho Lambda
- Policy attach vào role đó
- Bucket policy nếu dùng cross-account
- VPC endpoint nếu Lambda chạy trong VPC
- Security group rule cho endpoint
Chỉ để đọc một file từ S3. Năm bước. Và khi có lỗi? CloudWatch log gần như vô dụng trong việc debug IAM — bạn phải chờ vài phút mới thấy AccessDenied reason.
Theo một khảo sát của Datadog năm 2025, 67% security incident trên AWS liên quan đến cấu hình IAM sai — không phải do hacker tinh vi, mà do developer không hiểu nổi policy của chính developer đó.
2. Chi Phí Egress — "9 Cent Cho Mỗi GB? Nghiêm Túc À?"
AWS tính phí data transfer ra ngoài (egress) khoảng $0.09/GB. Nghe nhỏ? Hãy nhân với traffic thực tế:
- 1TB/tháng = $90
- 10TB/tháng = $900
- 100TB/tháng = $9,000
Và đây chỉ là data transfer ra internet. Nội bộ AWS cũng tính phí giữa các AZ ($0.01-0.02/GB), giữa các region ($0.02/GB), thậm chí giữa VPC khác nhau trong cùng region.
Kết quả: hóa đơn AWS tháng nào cũng có những khoản "không hiểu từ đâu ra". Đặc biệt với team dùng microservices — service A gọi service B gọi service C, mỗi lần gọi đều tốn tiền transfer.
3. Lambda Lock-in — Dễ Vào, Khó Ra
AWS Lambda là ví dụ điển hình của vendor lock-in. Khi bạn đã viết:
- Event source mapping với SQS, SNS, API Gateway
- Lambda Layers cho shared dependencies
- Step Functions orchestration
- Lambda@Edge cho CloudFront
...thì việc di chuyển sang bất kỳ đâu khác gần như là viết lại từ đầu. Không chỉ code, mà cả kiến trúc.
Theo kinh nghiệm thực tế: team từng mất 3 tháng chỉ để refactor Lambda functions sang container-based deployment. Lý do? Lambda cold start quá chậm cho latency-sensitive endpoints, nhưng gỡ ra thì phải rewrite toàn bộ event handling.
4. Hóa Đơn "Ma" — Hidden Costs Ở Khắp Mọi Nơi
AWS billing là một skill riêng mà developer bình thường không nên cần phải học. Nhưng bạn phải học, nếu không muốn nhận hóa đơn bất ngờ.
Những chi phí ẩn phổ biến:
- NAT Gateway: $0.045/hour + $0.045/GB processed. Một NAT Gateway chạy 24/7 tốn ~$33/tháng, chưa kể data transfer.
- CloudWatch Logs: $0.50/GB ingested. Log nhiều = hóa đơn khủng.
- S3 requests: PUT, COPY, POST, LIST đều tính phí. Mỗi request chỉ $0.005, nhưng hàng triệu request thì...
- EBS snapshots: Tự động accumulate theo thời gian, không ai cleanup.
DynamoDB là trường hợp nổi tiếng — nhiều developer nhận hóa đơn $75+ chỉ trong một ngày thử nghiệm, vì không hiểu read/write capacity units hoạt động thế nào.
5. Sự Phức Tạp Tăng Theo Cấp Số Nhân
AWS có hơn 200 services. Con số này nghe có vẻ ấn tượng, nhưng thực tế phần lớn developer chỉ dùng 10-15 services thường xuyên. Số còn lại tạo ra "nghịch lý lựa chọn" — bạn không biết nên dùng service nào, và mỗi quyết định đều có thể tốn kém.
Một team 5 người muốn deploy ứng dụng web đơn giản trên AWS cần ít nhất:
- EC2 hoặc ECS cho compute
- RDS cho database
- S3 cho static assets
- CloudFront cho CDN
- Route 53 cho DNS
- ACM cho SSL certificate
- ALB cho load balancer
- IAM cho permissions
- VPC cho networking
- CloudWatch cho monitoring
10 services chỉ để deploy một web app. Trên DigitalOcean hoặc Railway, bạn cần 1-2 clicks.
Counter-argument: AWS Vẫn Có Lý Do Tồn Tại
Trước khi quyết định "rời bỏ AWS", hãy cân nhắc:
AWS không sinh ra để đơn giản. Nó sinh ra để linh hoạt. Nếu bạn cần multi-region deployment, compliance certifications (HIPAA, SOC 2, PCI DSS), hoặc scale từ 0 đến 100M users — AWS là lựa chọn đúng.
Chi phí egress cao, nhưng AWS có CDN (CloudFront) với giá rẻ hơn. Vấn đề là bạn phải chủ động tối ưu, không phải AWS tự lo cho bạn.
Độ phức tạp đi kèm quyền kiểm soát. Trên DigitalOcean bạn không thể fine-tune IAM policy ở cấp granularity như AWS. Với startup nhỏ, đó là feature. Với enterprise, đó là limitation.
Lời Khuyên Thực Tế
Nếu team bạn < 10 người:
Đừng dùng AWS. Seriously. Dùng Railway, Render, Fly.io, hoặc Vercel. Chi phí thấp hơn, đơn giản hơn, và bạn tập trung vào code thay vì infra.
Nếu bạn đã ở AWS và muốn tối ưu:
- Tắt NAT Gateway nếu không cần — dùng VPC endpoints cho S3, DynamoDB thay vì NAT
- Dùng Savings Plans thay vì On-Demand — tiết kiệm 30-60%
- Cleanup resources định kỳ — EBS snapshots, unused Elastic IPs, old S3 versions
- Dùng AWS Cost Explorer + Budget Alerts — set alert khi chi phí vượt ngưỡng
- Xem xét multi-cloud hoặc hybrid — chạy workload chính trên AWS, nhưng dùng Cloudflare R2 thay S3 (free egress)
Nếu bạn đang evaluate cloud provider:
Đừng chọn AWS chỉ vì "ai cũng dùng". Hãy chọn dựa trên:
- Team expertise: team bạn giỏi gì?
- Workload requirements: cần scale bao nhiêu?
- Budget: startup hay enterprise?
- Vendor lock-in tolerance: sẵn sàng lock-in bao lâu?
Kết Luận
AWS là công cụ mạnh, nhưng không phải lúc nào cũng là lựa chọn tốt nhất. Bài viết viral trên HN không phải anti-AWS — nó là lời nhắc nhở rằng độ phức tạp có chi phí, và developer nên tỉnh táo đánh giá trade-off.
Câu hỏi không phải "AWS hay không AWS", mà là "mức độ phức tạp nào bạn sẵn sàng chấp nhận?"
Nếu team bạn đang đau đầu với AWS, hãy bắt đầu bằng việc audit chi phí — thường thì vấn đề nằm ở chỗ bạn dùng quá nhiều thứ không cần thiết.
Tham khảo: