While preparing for the AWS SAP-C02, many candidates get confused by VPC networking for serverless workloads. In the real world, this is fundamentally a decision about egress traffic patterns, IP predictability, and the hidden cost of NAT infrastructure. Let’s drill into a simulated scenario.
The Scenario #
GreenLeaf Analytics is modernizing their data processing platform using a serverless-first architecture. The analytics engine runs on AWS Lambda functions deployed within a VPC to access internal RDS databases. The company has signed a partnership agreement with DataEnrich Corp, a third-party data enrichment provider that enforces strict security policies: they only accept API requests originating from pre-registered public IPv4 addresses.
The security team at DataEnrich Corp requires GreenLeaf to provide a single, static public IP address that will be added to their allowlist before the integration can go live. Currently, the Lambda functions have no internet access configured.
Key Requirements #
Enable outbound internet connectivity for VPC-attached Lambda functions while providing a single, predictable public IPv4 address for third-party service integration, adhering to the partner’s IP allowlist requirements.
The Options #
- A) Deploy a NAT Gateway in a public subnet; associate an Elastic IP address with the NAT Gateway; configure the VPC route table to direct internet-bound traffic through the NAT Gateway.
- B) Deploy an egress-only Internet Gateway; associate an Elastic IP address with the egress-only Internet Gateway; configure the Lambda function’s elastic network interface to route traffic through the egress-only Internet Gateway.
- C) Deploy an Internet Gateway; associate an Elastic IP address with the Internet Gateway; configure Lambda functions to use the Internet Gateway directly.
- D) Deploy an Internet Gateway; associate an Elastic IP address with the Internet Gateway; configure the VPC public route table’s default route to use the Internet Gateway.
Correct Answer #
Option A is the optimal solution.
Step-by-Step Winning Logic #
This scenario requires understanding three fundamental VPC networking constraints:
-
Lambda in VPC requires ENI attachment - When you attach Lambda to a VPC, AWS creates Elastic Network Interfaces (ENIs) in your specified subnets. These ENIs enable access to VPC resources but remove default internet access.
-
Private subnet egress pattern - Lambda functions should be deployed in private subnets (not public subnets) following AWS security best practices. Private subnets cannot directly access the internet.
-
Static IP requirement for allowlisting - The third-party service requires a predictable, unchanging IP address. Only NAT Gateway with an associated Elastic IP provides this combination for resources in private subnets.
Why Option A works:
- NAT Gateway is deployed in a public subnet and automatically assigned an Elastic IP address
- The route table for the Lambda’s private subnet is updated with a default route (
0.0.0.0/0) pointing to the NAT Gateway - All outbound traffic from Lambda flows through the NAT Gateway and appears to originate from the single, static Elastic IP
- This architecture maintains Lambda in a private subnet (security best practice) while enabling internet egress
The FinOps consideration: NAT Gateway costs approximately $32.40/month (us-east-1) plus $0.045/GB of data processed. For a Lambda workload making API calls to a third-party service, the base cost is predictable, but data transfer costs scale with usage—making traffic optimization critical.
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option B? #
Technical impossibility - This option contains multiple fundamental errors:
- Egress-only Internet Gateways are IPv6-only - They do not support IPv4 traffic at all. The scenario explicitly requires IPv4 allowlisting.
- You cannot associate Elastic IPs with egress-only IGWs - Elastic IPs are IPv4 constructs; egress-only IGWs operate exclusively in the IPv6 space.
- ENI-level routing doesn’t exist - You cannot configure individual Lambda ENIs to route through specific gateways; routing is controlled by subnet-level route tables.
Exam trap: This option tests whether you understand the fundamental difference between egress-only IGWs (IPv6 outbound only) and NAT Gateways (IPv4 outbound with source NAT).
Why not Option C? #
Multiple architectural violations:
- Internet Gateways do not support Elastic IP association - IGWs themselves don’t have IP addresses; they provide a gateway for resources with public IPs to communicate with the internet.
- Lambda cannot “use” an IGW directly - Lambda functions do not have public IP addresses and cannot be directly associated with IGWs.
- Routing paradigm misunderstanding - This option fundamentally misunderstands how IGWs work. An IGW allows resources with public IPs in public subnets to communicate bidirectionally with the internet.
The core issue: For Lambda to use an IGW, it would need to be in a public subnet with a public IP—which is architecturally unsound and still wouldn’t provide a static IP (Lambda ENIs don’t receive persistent public IPs).
Cost trap: While IGWs have no hourly charge (unlike NAT Gateway), this solution is technically impossible, making cost comparison irrelevant.
Why not Option D? #
Incomplete and ineffective solution:
- Correct first step, wrong conclusion - Deploying an IGW and configuring the route table’s default route to use it is necessary for public subnet internet access, but insufficient for this scenario.
- No static IP mechanism - Even if you placed Lambda in a public subnet (bad practice), Lambda ENIs do not automatically receive Elastic IPs. You’d need to manually assign an EIP to each ENI, which:
- Violates the “single IP” requirement (each Lambda ENI would have different IPs)
- Creates operational complexity as Lambda scales ENIs dynamically
- Exposes Lambda directly to inbound internet traffic (security risk)
- Missing NAT layer - Without NAT Gateway, there’s no source NAT translation to a single static IP.
Exam insight: This distractor tests whether you understand that IGWs alone don’t provide source NAT or static IP aggregation—you need NAT Gateway for that functionality.
The Architect Blueprint #
graph TB
subgraph VPC["VPC (10.0.0.0/16)"]
subgraph PrivateSubnet["Private Subnet (10.0.1.0/24)"]
Lambda["Lambda Function
(ENI: 10.0.1.50)"]
end
subgraph PublicSubnet["Public Subnet (10.0.0.0/24)"]
NAT["NAT Gateway
(EIP: 203.0.113.42)"]
end
PrivateRT["Private Route Table
0.0.0.0/0 → NAT Gateway"]
PublicRT["Public Route Table
0.0.0.0/0 → Internet Gateway"]
end
IGW["Internet Gateway"]
ThirdParty["DataEnrich API
(Allowlist: 203.0.113.42)"]
Lambda -->|"Outbound traffic
Source: 10.0.1.50"| PrivateRT
PrivateRT -->|"Route to NAT"| NAT
NAT -->|"Source NAT
New Source: 203.0.113.42"| PublicRT
PublicRT --> IGW
IGW -->|"All traffic shows
source IP: 203.0.113.42"| ThirdParty
style Lambda fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style NAT fill:#8C4FFF,stroke:#232F3E,stroke-width:2px,color:#fff
style IGW fill:#3F8624,stroke:#232F3E,stroke-width:2px,color:#fff
style ThirdParty fill:#DD344C,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Flow Explanation:
Lambda functions in the private subnet send outbound requests through the private route table to the NAT Gateway in the public subnet, which performs source NAT translation to the static Elastic IP (203.0.113.42) before forwarding through the Internet Gateway to the third-party service.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A) NAT Gateway | Low - Standard VPC pattern; well-documented | Medium - $32.40/month base + $0.045/GB data processed (~$100-300/month for typical workloads) | ✅ Single static IP for allowlisting ✅ AWS-managed service (no patching) ✅ Auto-scaling to 100 Gbps ✅ Security best practice (Lambda in private subnet) |
❌ Recurring hourly cost even if idle ❌ Data processing charges can escalate ❌ Single AZ (requires multi-AZ deployment for HA) |
| B) Egress-only IGW | N/A - Technically invalid | N/A - Cannot implement | ❌ IPv6-only (scenario requires IPv4) ❌ Cannot associate Elastic IPs ❌ Does not support the use case |
This option is architecturally impossible for IPv4 requirements |
| C) IGW Direct | N/A - Technically invalid | Low - $0/month for IGW itself | ❌ IGWs don’t accept EIP association ❌ Lambda cannot use IGW without public subnet + public IP ❌ No static IP mechanism |
Fundamentally misunderstands Lambda VPC networking |
| D) IGW + Public Route | High - Requires custom ENI management | High - $3.60/month per EIP × dynamic ENI count (potentially $50-500/month) + security risks | ✅ IGW has no hourly cost | ❌ Requires Lambda in public subnet (anti-pattern) ❌ Each ENI needs separate EIP (multi-IP problem) ❌ Inbound exposure risk ❌ Operational complexity with dynamic scaling |
FinOps Key Insight:
While NAT Gateway’s $32.40/month base cost seems high compared to the “free” Internet Gateway, the data processing cost of $0.045/GB is the real variable. For a Lambda function making lightweight API calls (e.g., 1,000 calls/day × 10KB response = ~300MB/day), monthly data costs would only add ~$0.40. The break-even analysis should focus on traffic volume and consider VPC endpoints for AWS service traffic to bypass NAT Gateway entirely.
Real-World Practitioner Insight #
Exam Rule #
For the SAP-C02 exam, remember this decision tree:
- If the scenario mentions “Lambda in VPC” + “static public IP” + “third-party allowlist” → Always choose NAT Gateway with Elastic IP
- If the scenario specifies IPv6-only outbound → Choose Egress-only Internet Gateway
- If the question asks about cost optimization for AWS service access (S3, DynamoDB) from Lambda in VPC → Choose VPC Endpoints (not tested in this question but common distractor)
Real World #
In production environments, we layer additional optimizations:
-
Traffic Segmentation Strategy
- Use VPC Endpoints (Gateway or Interface) for AWS service traffic (S3, DynamoDB, SQS) to bypass NAT Gateway entirely—this can reduce data processing costs by 60-80% for AWS-heavy workloads
- Reserve NAT Gateway exclusively for true internet egress (third-party APIs, external services)
-
Multi-AZ High Availability
- The exam scenario doesn’t mention HA, but production deployments require NAT Gateways in multiple Availability Zones
- Cost impact: 2× base cost ($64.80/month for two AZs) but eliminates single point of failure
-
Cost Monitoring & Alerting
- Implement CloudWatch Alarms on BytesOutToDestination metric for NAT Gateway
- Set billing alerts when data processing costs exceed expected thresholds (e.g., >$50/month)
- Use VPC Flow Logs to identify top talkers and opportunities for VPC Endpoint migration
-
Alternative Architecture Consideration
- For extremely cost-sensitive workloads with low traffic (<1GB/month), consider NAT Instance on t4g.nano (~$3/month) instead of NAT Gateway
- Trade-off: Operational burden of managing EC2 instance vs. AWS-managed service
- Not recommended for production due to single instance failure risk and manual scaling
-
IPv6 Migration Path
- If the third-party service supported IPv6, you could use Egress-only Internet Gateway (free) and eliminate NAT Gateway costs entirely
- This is a strategic conversation to have with partners during contract negotiations
The Real FinOps Question:
“Is the third-party integration valuable enough to justify $400-800/year in NAT infrastructure costs?” If the answer is yes, optimize data transfer. If no, consider alternative integration patterns (API Gateway proxy, scheduled batch jobs to minimize connection time, or renegotiating partner requirements).