While preparing for the AWS SAP-C02, many candidates get confused by multi-account network policy management. In the real world, this is fundamentally a decision about operational overhead vs. architectural elegance. Let’s drill into a simulated scenario.
The Scenario #
A global financial services company operates 52 AWS accounts under AWS Organizations. The network architecture team has designated one account as the Network Hub Account, which hosts a Transit Gateway shared with all member accounts via AWS Resource Access Manager (RAM). All 18 regional branch offices connect to AWS through Site-to-Site VPN terminating on the Transit Gateway.
AWS Config is enabled organization-wide for compliance tracking. The security engineering team must maintain a single source of truth for the IP address ranges of all branch offices (CIDR blocks like 10.20.0.0/16, 192.168.50.0/24, etc.). Development teams across all accounts need to reference this list when configuring security group rules to allow inbound traffic from corporate networks.
Key Requirements #
Implement a solution that:
- Centralizes IP range management with minimal operational overhead
- Allows application teams to self-service security group updates
- Eliminates drift and manual synchronization across 52 accounts
- Minimizes cost and architectural complexity
The Options #
A) Host a JSON file in Amazon S3 containing all internal IP ranges. Use AWS Config to trigger an Amazon SNS topic in each account when the file is updated. Subscribe an AWS Lambda function to each SNS topic to programmatically update security group rules across all accounts.
B) Create a custom AWS Config Managed Rule containing all internal IP ranges. Use the rule to evaluate security groups in each account for compliance. Configure automatic remediation to modify non-compliant security groups.
C) In the Network Hub Account, create a VPC Prefix List containing all internal IP ranges. Use AWS Resource Access Manager (RAM) to share the prefix list with all member accounts. In member accounts, reference the shared prefix list directly in security group rules.
D) In the Network Hub Account, create a security group containing all internal IP ranges. In member accounts’ security groups, reference the hub account’s security group using nested security group syntax (/sg-1a2b3c4d).
Correct Answer #
Option C – VPC Prefix Lists with AWS RAM sharing.
💎 The Architect’s Deep Dive: Why Options Fail #
Step-by-Step Winning Logic #
This solution achieves architectural elegance through native primitives:
- Single Source of Truth: The prefix list exists only in the Network Hub Account—updates propagate automatically via RAM.
- Zero Custom Code: No Lambda functions, no S3 event processors, no SNS topics to maintain.
- Self-Service Capability: Application teams reference the shared prefix list ID (e.g.,
pl-12345678) directly in security group rules—no tickets to the network team. - Auditability: AWS Config can still track security group changes; the prefix list itself is version-controlled within AWS.
- Cost Optimization: Prefix lists are free. RAM sharing is free. You pay only for the VPN connections you already have.
The Trade-off: This solution optimizes for operational simplicity at the cost of slight architectural coupling (all accounts depend on the hub account’s prefix list). However, since the hub account already owns the Transit Gateway, this coupling aligns with the existing network topology.
The Traps (Distractor Analysis) #
-
Why not Option A?
Over-engineered and expensive. This creates a distributed event-driven system requiring:- 52 Lambda functions (one per account)
- 52 SNS topics
- S3 event notifications
- IAM roles for cross-account Lambda execution
- Ongoing maintenance of JSON schema and parsing logic
Monthly cost estimate: ~$150–$300 (Lambda invocations, SNS, S3 requests) plus engineering hours for debugging event propagation failures. This violates the “least operational overhead” requirement.
-
Why not Option B?
AWS Config Rules cannot store IP ranges. Config rules evaluate resource compliance against logic—they don’t function as data stores. You cannot “embed” a list of IPs into a Config rule and have it auto-remediate security groups. This option reflects a fundamental misunderstanding of AWS Config’s purpose (compliance detection, not configuration management). -
Why not Option D?
Cross-account security group referencing doesn’t work this way. You can reference security groups within the same VPC or across peered VPCs in the same region, but you cannot reference a security group in Account A from a security group in Account B unless they share a VPC (which defeats the multi-account isolation model). This is a technical impossibility disguised as a plausible answer.
The Architect Blueprint #
graph TB
subgraph "Network Hub Account"
PL[VPC Prefix List
10.20.0.0/16
192.168.50.0/24
...]
RAM[AWS Resource
Access Manager]
TGW[Transit Gateway]
end
subgraph "Member Account 1"
SG1[Security Group
Inbound: pl-12345678]
EC2_1[Application
Instances]
end
subgraph "Member Account 2"
SG2[Security Group
Inbound: pl-12345678]
ECS[ECS Tasks]
end
Office1[Branch Office 1
10.20.0.0/16] -->|Site-to-Site VPN| TGW
Office2[Branch Office 2
192.168.50.0/24] -->|Site-to-Site VPN| TGW
PL -->|Share via RAM| RAM
RAM -.->|Prefix List ID| SG1
RAM -.->|Prefix List ID| SG2
SG1 --> EC2_1
SG2 --> ECS
TGW -->|Routing| SG1
TGW -->|Routing| SG2
style PL fill:#ff9900,stroke:#232F3E,stroke-width:3px,color:#fff
style RAM fill:#DD344C,stroke:#232F3E,stroke-width:2px,color:#fff
style TGW fill:#8C4FFF,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: The prefix list is created once in the hub account and shared via RAM; member accounts reference it by ID in security group rules without duplicating the IP data.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A) S3 + Lambda + SNS | High (6 services orchestrated) | $200–$400 (Lambda invocations × 52 accounts, SNS delivery, S3 API calls, CloudWatch Logs) | - Familiar event-driven pattern - Version history in S3 |
- Requires custom code maintenance - Lambda cold starts delay propagation - Event-driven debugging complexity - High operational burden |
| B) AWS Config Custom Rule | Impossible | N/A | - Conceptually appealing (compliance-as-code) | - AWS Config rules don’t store data - Cannot auto-remediate to inject IPs - Misunderstands Config’s purpose |
| C) VPC Prefix List + RAM ✅ | Low (2 AWS-native features) | $0 (Prefix lists free, RAM free; VPN costs already sunk) | - Zero custom code - Instant propagation - Native AWS integration - Self-service for app teams - Centralized updates |
- Slight dependency on hub account availability (mitigated by AWS SLA) - Limited to 1,000 entries per prefix list (acceptable for branch offices) |
| D) Nested Security Groups | N/A | N/A | - None (doesn’t work cross-account) | - Technically impossible in multi-account, non-peered VPC scenario - Requires VPC peering or shared VPC (defeats isolation) |
FinOps Insight: Option C eliminates $200–$400/month in compute/event costs while reducing Mean Time to Resolution (MTTR) for IP updates from hours (Lambda deployment cycles) to seconds (RAM propagation).
Real-World Practitioner Insight #
Exam Rule #
“When you see ’least operational overhead’ + ‘centralized management’ + AWS Organizations, always prefer AWS-native sharing mechanisms (RAM, SCPs, delegated admin) over custom Lambda orchestration.”
Real World #
In production, we’d also implement:
- Prefix List Versioning: Use infrastructure-as-code (Terraform/CloudFormation) to track changes to the prefix list with Git commits.
- Approval Workflow: Require pull request reviews before updating the prefix list to prevent accidental IP range deletions.
- Monitor RAM Share Status: Set up EventBridge rules to alert if RAM sharing fails to propagate to new accounts.
- Consider AWS Network Firewall: For more advanced use cases (DPI, threat intelligence), we might layer AWS Network Firewall with domain-based filtering on top of this prefix list foundation.
The Hidden Trade-off: VPC Prefix Lists have a hard limit of 1,000 entries. If the company later acquires a competitor with 500 additional branch offices, you’d need to architect prefix list chaining or migrate to AWS Network Firewall’s flexible rule groups. The exam assumes constraints fit within AWS service limits.