Lambda trong VPC

Hàm Lambda được triển khai bên ngoài VPC của bạn (trong VPC do AWS sở hữu).
Do đó, hàm Lambda không thể truy cập các tài nguyên bên trong VPC của bạn (như RDS, ElastiCache, hoặc internal ELB...).

Sơ đồ mô tả Default Lambda Deployment:

Tuy nhiên, Lambda không thể truy cập được các tài nguyên nằm trong private subnet của VPC, ví dụ như Private RDS, vì:

Mặc định Lambda không có ENI (Elastic Network Interface) gắn vào VPC của bạn, nên không thể định tuyến nội bộ để gọi vào private subnet.

Bạn phải định nghĩa VPC ID, các Subnet và Security Group cho Lambda.
Lambda sẽ tự động tạo ra một ENI (Elastic Network Interface) trong các subnet mà bạn chỉ định.

Khi bạn cấu hình Lambda chạy bên trong VPC, quá trình hoạt động sẽ như sau:

Lambda function được gán VPC ID, private subnet, và security group trong cấu hình.
AWS tự động tạo ra một ENI (Elastic Network Interface) – tức là một network interface– nằm trong subnet chỉ định.
ENI này giúp Lambda kết nối trực tiếp với các tài nguyên nằm trong VPC, ví dụ Amazon RDS.
Security Group của Lambda (gắn vào ENI) phải được cấu hình phù hợp để cho phép truy cập tới port dịch vụ của RDS (thường là TCP 3306 nếu dùng MySQL).
Đồng thời, Security Group của RDS cũng cần cho phép inbound từ Security Group của Lambda.

Nếu Lambda function truy cập trực tiếp vào database, chúng có thể mở quá nhiều connection khi tải lớn.
RDS Proxy:
- Tăng khả năng mở rộng bằng cách pool và share connection tới DB.
- Tăng tính sẵn sàng bằng cách giảm 66% thời gian failover và giữ kết nối hiện tại.
- Tăng bảo mật bằng cách áp dụng xác thực IAM và lưu thông tin đăng nhập trong Secrets Manager.
Lambda function bắt buộc phải deploy trong VPC, vì RDS Proxy không bao giờ được public.

Nhiều Lambda functions cùng nằm trong VPC.
Các Lambda này không kết nối trực tiếp với RDS, mà kết nối thông qua RDS Proxy.
RDS Proxy nằm trong private subnet, làm trung gian giữa Lambda và RDS.
Proxy sẽ quản lý pool connection, giảm số lượng connection mở thực tế tới DB → tránh hiện tượng connection exhaustion (quá nhiều connection làm DB nghẽn).

Gọi hàm Lambda từ bên trong instance cơ sở dữ liệu (DB instance) của bạn
Cho phép bạn xử lý các sự kiện dữ liệu (data events) từ bên trong cơ sở dữ liệu
Hỗ trợ cho RDS sử dụng PostgreSQL và Aurora sử dụng MySQL
Phải cho phép traffic outbound đến hàm Lambda từ trong instance DB (bao gồm các tùy chọn Public, NAT Gateway, hoặc VPC Endpoints)
Instance DB phải có đủ quyền để gọi hàm Lambda, bao gồm:
- Lambda Resource-based Policy
- IAM Policy

Sơ đồ bên phải mô tả luồng xử lý:

User thực hiện thao tác ghi dữ liệu (ví dụ: INSERT ) vào Amazon RDS DB Instance.
Cơ sở dữ liệu (PostgreSQL/Aurora MySQL) thực hiện gọi ra một AWS Lambda Function dựa trên sự kiện INSERT đó.
Lambda Function thực hiện logic nghiệp vụ, ví dụ như gửi email xác nhận thông qua Amazon SES.
Luồng yêu cầu RDS phải có đủ quyền gọi Lambda, nghĩa là:
- Cho phép outbound traffic (qua Internet hoặc VPC endpoint tùy thiết lập VPC)
- Lambda cần cấp quyền gọi từ RDS thông qua resource-based policy
- IAM Role gán cho RDS cần được cấp quyền thực thi hàm Lambda tương ứng.

Các thông báo cung cấp thông tin liên quan đến chính DB instance (ví dụ: được tạo, dừng, khởi động, …)
Không cung cấp thông tin nào về dữ liệu bên trong
Có thể đăng ký nhận thông báo theo các loại sự kiện sau:
- DB instance
- DB snapshot
- DB Parameter Group
- DB Security Group
- RDS Proxy
- Custom Engine Version
Các sự kiện gần thời gian thực (độ trễ tối đa ~5 phút)
Gửi thông báo tới SNS hoặc đăng ký theo dõi sự kiện thông qua EventBridge

Giải thích sơ đồ luồng

Sơ đồ mô tả cách Amazon RDS DB Instance phát sinh và gửi thông báo sự kiện:
Khi một sự kiện xảy ra trên RDS DB Instance (ví dụ: khởi động lại), hệ thống có thể kích hoạt:
- SNS (Simple Notification Service) → để đẩy thông báo đến:
  - SQS Queue
  - Lambda Function
  - … (các subscriber khác)
- EventBridge → để kích hoạt các rule định nghĩa theo logic phức tạp hơn, có thể:
  - Gọi trực tiếp Lambda Function
Kết nối tới các dịch vụ AWS khác theo mô hình sự kiện (event-driven architecture)