- Do I need a NAT Gateway?
- How do I configure route tables?
- What security group rules are required?

Let’s dive in.

Architecture Overview

• Lambda (inside a private subnet)
 • Internal API (e.g., EC2, ECS, or ALB, in another private subnet)
 • Private Subnets (for Lambda and API)
 • Public Subnet (optional, for NAT Gateway if internet access is needed)
 • Security Groups to control access
 • Route Tables to define network routing

Network Layout

VPC (10.0.0.0/16)
 │
 ├── Public Subnet (10.0.0.0/24)
 │   └── NAT Gateway + Internet Gateway
 │
 ├── Private Subnet A (10.0.1.0/24) — Lambda
 │
 └── Private Subnet B (10.0.2.0/24) — Internal API

Route Table Setup

RT-Lambda (Private Subnet A)

 | Destination | Target
 | 10.0.0.0/16 | local
 | 0.0.0.0/0 | NAT Gateway (only if internet access is needed)

RT-API (Private Subnet B)

 | Destination | Target
 | 10.0.0.0/16 | local

Security Group Configuration

Lambda Security Group (SG-Lambda)

• Outbound Rule: Allow traffic to the API security group on the API’s port (e.g., 443)

Internal API Security Group (SG-API)

• Inbound Rule: Allow traffic from SG-Lambda on the API port (e.g., 443)

Do I Need a NAT Gateway?

• Yes if your Lambda needs external access (external APIs, internet).
 • No if your Lambda only calls internal services within the same VPC.

Best Practices

• Use Security Group to Security Group rules instead of IPs for dynamic, secure access.
 • Avoid public IPs on private subnets.
 • Use AWS Secrets Manager for credentials.
 • Monitor using CloudWatch Logs and X-Ray.
 • Scale internal APIs with ALB + Auto Scaling Group or ECS.

Final Thoughts

By isolating your Lambda and API in private subnets and using scoped security groups, you’re ensuring a secure, reliable, and scalable architecture. AWS provides the flexibility needed to achieve this with minimal cost and maximum security.