While preparing for the AWS SAP-C02, many candidates get confused by BYOIP (Bring Your Own IP) use cases and when to use Global Accelerator vs. NAT Gateway. In the real world, this is fundamentally a decision about outbound traffic source IP stability vs. inbound traffic optimization. Let’s drill into a simulated scenario.
The Scenario #
GlobalMedix Inc. operates a patient appointment scheduling web application currently hosted on-premises. This application integrates with PharmaCentral, a third-party pharmaceutical data API that operates behind a strict firewall. PharmaCentral’s security policy requires each client to provide exactly one public CIDR block for IP whitelisting—no ranges, no dynamic IPs.
GlobalMedix has decided to migrate the web application to AWS. The planned architecture includes:
- Application Load Balancer (ALB) in public subnets for distributing incoming user traffic
- Amazon EC2 instances in private subnets running the application tier
- NAT Gateway in public subnets to provide internet access for the EC2 instances
The migration is scheduled for next quarter, but the solutions architect must ensure that after migration, the application can continue to successfully call the PharmaCentral API.
Key Requirements #
Ensure the migrated web application can call the third-party PharmaCentral API, which only accepts requests from a single, pre-registered public CIDR block.
The Options #
- A) Associate a pool of customer-owned public IP addresses to the VPC and enable public IP addressing for public subnets in the VPC.
- B) Register a pool of customer-owned public IP addresses in the AWS account, create Elastic IP addresses from this pool, and assign them to the NAT Gateways in the VPC.
- C) Create Elastic IP addresses from the customer-owned IP address pool and assign these static Elastic IPs to the Application Load Balancer.
- D) Register a pool of customer-owned public IP addresses in the AWS account, configure AWS Global Accelerator to use Elastic IPs from this pool, and set the ALB as the accelerator endpoint.
Correct Answer #
Option B — Register customer-owned public IP addresses (BYOIP), create Elastic IP addresses from the pool, and assign them to NAT Gateways.
Step-by-Step Winning Logic #
The core technical constraint is outbound IP address stability. When your EC2 instances in private subnets call the PharmaCentral API, they route through the NAT Gateway. The NAT Gateway’s Elastic IP becomes the source IP that PharmaCentral sees and must whitelist.
Why Option B wins:
-
BYOIP Support for NAT Gateway: AWS allows you to bring your own IP addresses (BYOIP) and assign them as Elastic IPs to NAT Gateways. This gives you full control over the IP address used for outbound traffic.
-
Correct Traffic Path: EC2 instances (private subnet) → NAT Gateway (public subnet) → Internet → Third-Party API. The NAT Gateway is the egress point.
-
Single CIDR Block Requirement: You can register a /24 CIDR block (or smaller) via BYOIP, extract one or more Elastic IPs, and provide this single CIDR to PharmaCentral for whitelisting.
-
Cost Efficiency: Only requires NAT Gateway + BYOIP registration (one-time). No additional services.
-
Operational Simplicity: Standard VPC networking pattern with deterministic IP addressing.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
Why not Option A? #
“Associate customer-owned IPs to the VPC and enable public IP addressing for public subnets.”
- Trap: This option conflates VPC-level IP association with instance-level public IP assignment.
- Why it fails: Enabling public IP addressing for public subnets assigns AWS-managed dynamic IPs to instances launched in those subnets, not your customer-owned IPs. You cannot directly “associate” a BYOIP pool to a VPC in a way that auto-assigns those IPs to instances.
- Technical gap: Even if you could, your EC2 instances are in private subnets—they don’t get public IPs. The outbound traffic still routes through NAT Gateway.
Why not Option C? #
“Assign customer-owned Elastic IPs to the Application Load Balancer.”
- Trap: This option targets the wrong traffic direction.
- Why it fails: The ALB handles inbound traffic from users to your application. The third-party API doesn’t care about your ALB’s IP—it cares about the source IP of outbound requests from your EC2 instances.
- Technical gap: ALBs do not support Elastic IP assignment in the traditional sense (they use AWS-managed IPs). More importantly, ALB IPs are irrelevant for egress traffic to external APIs.
- Cost: Even if possible, this adds unnecessary complexity with zero functional benefit.
Why not Option D? #
“Use AWS Global Accelerator with BYOIP and ALB as endpoint.”
- Trap: This is the most expensive and over-engineered option, targeting the wrong problem.
- Why it fails:
- Global Accelerator is designed to optimize inbound traffic routing to your application using AWS’s global network and static Anycast IPs.
- It does nothing for outbound traffic from your EC2 instances to external APIs.
- The third-party API sees the source IP of your NAT Gateway, not Global Accelerator’s IPs.
- Cost impact:
- Global Accelerator charges
$0.025/hour ($18/month) per accelerator. - Data Transfer Premium (DTP) charges: ~$0.015/GB for traffic over AWS backbone (on top of standard data transfer).
- For a web app with 10 TB/month egress, this adds ~$150/month in DTP fees alone, for zero functional gain in this use case.
- Global Accelerator charges
- Complexity: Adds another service layer (Global Accelerator) with no operational benefit.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
User([End Users]) -->|HTTPS| ALB[Application Load Balancer
Public Subnet]
ALB -->|HTTP| EC2[EC2 Instances
Private Subnet
10.0.1.0/24]
EC2 -->|Outbound API Call| NAT[NAT Gateway
Public Subnet
EIP: 203.0.113.5
BYOIP Pool]
NAT -->|Source IP: 203.0.113.5| API[PharmaCentral API
Whitelist: 203.0.113.0/24]
style NAT fill:#4CAF50,stroke:#333,stroke-width:3px,color:#fff
style API fill:#FF9800,stroke:#333,stroke-width:2px,color:#fff
style EC2 fill:#2196F3,stroke:#333,stroke-width:2px,color:#fff
Diagram Note: Outbound API calls from EC2 instances flow through the NAT Gateway, which uses the BYOIP-derived Elastic IP (203.0.113.5) as the source IP. This IP is pre-registered in PharmaCentral’s whitelist.
🔐 The Decision Matrix #
This matrix compares all options across cost, complexity, and operational impact, making the trade-offs explicit and the correct choice logically defensible.
At the professional level, the exam expects you to justify your choice by explicitly comparing cost, complexity, and operational impact.
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A) BYOIP to VPC + Public IP for Subnets | Medium | ~$45 (NAT Gateway) | - Uses BYOIP | - Doesn’t assign customer IPs to instances - EC2s are in private subnets - Doesn’t solve the problem |
| B) BYOIP + EIP on NAT Gateway | Low | ~$45 (NAT Gateway + $3.60 EIP) | - Direct solution - Standard AWS pattern - Deterministic egress IP - Lowest cost |
- None for this use case |
| C) BYOIP EIP on ALB | High | ~$25 (ALB) | - None | - ALBs don’t support custom EIPs - Targets wrong traffic direction - Doesn’t solve the problem |
| D) Global Accelerator + BYOIP | Very High | ~$216 (GA: $18 + DTP: ~$150 + ALB: $25 + NAT: $45) | - Supports BYOIP - Good for global inbound optimization |
- Massive cost overhead ($171/mo extra) - Solves wrong problem (inbound, not outbound) - Operational complexity - Zero benefit for egress traffic |
Cost Assumptions:
- NAT Gateway:
$0.045/hour ($32/mo) +$0.045/GB processed ($13/mo for 300 GB) - EIP (when not attached to running instance): $0.005/hour (~$3.60/mo)
- ALB:
$0.0225/hour ($16/mo) + LCU charges (~$9/mo) - Global Accelerator: $0.025/hour (~$18/mo) + DTP fees ($0.015/GB)
- Data Transfer: Assuming 10 TB/month egress for Option D DTP calculation
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
For the SAP-C02 exam, when you see a third-party API with IP whitelisting + migration to AWS + EC2 in private subnets, always choose BYOIP + NAT Gateway with Elastic IP (Option B). Remember: outbound traffic = NAT Gateway; inbound traffic = ALB/NLB.
Real World #
In production environments, we would also consider:
-
Multiple NAT Gateways for HA: Deploy NAT Gateways in multiple Availability Zones. Each would get a separate EIP from your BYOIP pool. You’d need to register the entire /24 CIDR block (or larger) with PharmaCentral, not just a single IP.
-
NAT Gateway Single Point of Failure: For critical APIs, implement NAT Gateway health monitoring with CloudWatch alarms and automated failover.
-
BYOIP Limitations:
- AWS requires you to own a /24 or larger CIDR block.
- ROA (Route Origin Authorization) validation is required.
- Not all regions support BYOIP.
-
Alternative: AWS Transit Gateway + Centralized Egress VPC: For multi-account organizations, we’d use a hub-and-spoke model with centralized NAT Gateways in a shared services VPC.
-
IPv6 Considerations: If PharmaCentral supported IPv6, we could use Egress-Only Internet Gateways (free, no NAT required), though BYOIP for IPv6 has different requirements.
-
API Gateway + VPC Link: For certain use cases, we might front the third-party API with API Gateway using a VPC Link to a Network Load Balancer with static IPs, though this adds latency and cost.
-
Cost Optimization: For dev/test environments with low traffic, consider NAT Instances (self-managed EC2) instead of NAT Gateway to reduce costs from $45/month to ~$8/month (t3.nano), though this sacrifices managed scalability and HA.