Vấn đề của pure serverless
AWS Lambda mang lại developer experience rất mạnh: không quản lý hạ tầng, tự scale theo request, chỉ trả tiền khi dùng. Tuy nhiên khi xây dựng hệ thống thực tế, nhiều workload không vừa khít với mô hình một execution environment xử lý đúng một invocation và cold start có thể xảy ra bất cứ lúc nào.
Các trường hợp điển hình:
- Traffic ổn định ở mức cao, muốn tận dụng Compute Savings Plans hoặc Reserved Instances thay vì on-demand để giảm chi phí đáng kể.
- Cần instance types có đặc thù về CPU architecture (ví dụ Graviton), networking throughput hoặc memory profile mà classic Lambda execution environment không expose trực tiếp.
- Muốn giảm p99 latency cho một số path nhạy cảm mà vẫn giữ event-driven model với SQS, EventBridge, SNS.
Trước đây, để giải các bài toán trên thường phải migrate một phần sang ECS Fargate hoặc EC2 thuần — mất đi rất nhiều thứ đã được đầu tư: event source mapping, IAM model, versioning/alias, observability, deployment pipeline với SAM/CDK.
Lambda Managed Instances giải quyết như thế nào
Tính năng cho phép bạn tạo Capacity Provider ngay trong Lambda console hoặc IaC:
- Chọn VPC, subnets, security groups.
- Chỉ định instance types (hoặc để AWS recommend), max vCPU cho capacity provider.
- Cấu hình scaling (CPU policy hoặc manual max).
AWS lo toàn bộ: khởi tạo EC2 instances trong account của bạn, OS patching, lifecycle (instance có tuổi thọ giới hạn), load balancing, auto scaling khi traffic tăng. Function của bạn chỉ cần trỏ vào Capacity Provider ARN khi tạo hoặc update.
Điểm khác biệt quan trọng:
- Multi-concurrency: Một execution environment giờ có thể xử lý nhiều request đồng thời. Điều này thay đổi đáng kể cách tận dụng tài nguyên, đặc biệt với Node.js services vốn I/O-bound.
- Không cold start cho các môi trường đã được pre-provisioned trong capacity provider.
- Pricing gồm: Lambda request charges + EC2 instance charges (có thể apply existing Savings Plans/RI của bạn) + compute management fee (~15% trên EC2 on-demand).
- Vẫn giữ nguyên event integrations, IAM, CloudWatch, AppConfig extensions, và deployment tools.
Gần đây AWS còn bổ sung scheduled scaling cho Lambda Managed Instances thông qua EventBridge Scheduler — ví dụ tăng capacity trước giờ cao điểm, giảm về zero khi không có traffic.
Những điều cần cân nhắc khi áp dụng
Multi-concurrency đòi hỏi code hygiene tốt hơn. Các giả định kiểu "mỗi invocation là một process sạch" không còn đúng: tránh shared mutable state giữa requests, cẩn thận với temp file paths, connection pools, và global singletons. Trước khi bật, cần review và test kỹ các function dự định migrate.
Về chi phí: với workload ổn định, việc apply commitment-based pricing thường mang lại lợi ích rõ rệt so với classic Lambda. Tuy nhiên với traffic cực spiky, ngắn hạn, classic Lambda vẫn thường rẻ và đơn giản hơn.
Về kiến trúc: đây không phải là "tất cả hoặc không gì". Bạn có thể mix — một số consumer nhạy cảm latency hoặc cần specialized compute thì dùng Managed Instances, phần burst/spiky giữ nguyên classic Lambda. Vẫn nằm trong cùng event-driven fabric.
Khi nào nên thử
- Workload có pattern dự đoán được, volume đủ để benefit từ Reserved/Savings Plans.
- Cần performance profile mà classic Lambda execution không đáp ứng tốt.
- Muốn giảm cold start ảnh hưởng mà không muốn vận hành full container platform.
Ngược lại, nếu bạn đang ở giai đoạn early, traffic khó đoán, hoặc ưu tiên zero ops tối đa — hãy giữ classic Lambda.
Kết
Lambda Managed Instances là một ví dụ điển hình về việc cloud provider lấp dần khoảng trống giữa các abstraction layers. Đối với ai đang làm system optimization trên AWS, nó cung cấp thêm một lựa chọn sắc bén: giữ được phần lớn lợi ích của serverless DX trong khi mở khóa khả năng kiểm soát compute và tối ưu chi phí mà trước kia chỉ có khi chấp nhận vận hành nhiều hơn.
Quan trọng nhất là hiểu rõ trade-off mới — đặc biệt quanh execution model và multi-concurrency — rồi đo đạc, pilot trước khi rollout rộng. Đó chính là cách tiếp cận thực tế khi tối ưu hệ thống production.