While preparing for the AWS SAP-C02, many candidates confuse resource sharing mechanisms (RAM vs. SCPs vs. Service Catalog) and miss the automation requirements. In the real world, this is fundamentally a decision about Centralized Governance vs. Operational Scalability. A poorly designed multi-account network can cost you $50K+/year in unnecessary Transit Gateway data processing fees and create a deployment bottleneck that blocks every new product team. Let’s drill into a simulated scenario.
The Scenario #
GlobalFinTech Corp operates 50 AWS accounts organized under AWS Organizations, supporting independent product teams across payments, lending, and insurance divisions. Each account hosts 3-8 VPCs for development, staging, and production environments. The network team has been manually creating VPC peering connections, but this approach has become unsustainable鈥攖hey’re now managing over 200 peering relationships with inconsistent routing policies.
Leadership has approved a centralized networking initiative using AWS Transit Gateway. The requirements are strict: whenever a new account is provisioned (which happens 2-3 times per quarter as new products launch), the networking infrastructure must be automatically deployed without manual intervention from the central cloud team.
Key Requirements #
Implement an automated, scalable solution that:
- Establishes Transit Gateway connectivity between all member account VPCs
- Automatically provisions networking infrastructure when new accounts join the organization
- Maintains centralized governance over the Transit Gateway resource
- Minimizes operational overhead for the 3-person cloud platform team
The Options: #
Select TWO:
- A) Share the Transit Gateway from the management account to member accounts using AWS Resource Access Manager (RAM).
- B) Share the Transit Gateway from the management account to member accounts using AWS Organizations Service Control Policies (SCPs).
- C) Create VPCs in each AWS account within the organization, configure them to use identical CIDR ranges and subnets as the infrastructure account VPC, and establish VPC peering connections between each member account VPC and the infrastructure account VPC.
- D) Launch an AWS CloudFormation StackSet from the management account to automatically create VPCs and Transit Gateway attachments in member accounts, associating attachments with the centrally-managed Transit Gateway using its Transit Gateway ID.
- E) Share the Transit Gateway from the management account to member accounts using AWS Service Catalog.
Correct Answer #
A and D.
Step-by-Step Winning Logic #
This scenario requires two distinct capabilities:
1. Resource Sharing (Option A - AWS RAM)
- Transit Gateway is created once in a central account (typically a dedicated networking/infrastructure account, not necessarily the management account in production, but the question uses “management account” as the source)
- AWS Resource Access Manager (RAM) is the only native AWS service designed to share Transit Gateways across accounts within an organization
- When shared via RAM, member accounts can create attachments to the Transit Gateway without needing their own separate gateways
- This creates a hub-and-spoke model with centralized routing policy and cost allocation
2. Automation at Scale (Option D - CloudFormation StackSets)
- CloudFormation StackSets enable you to deploy identical infrastructure across multiple accounts and regions with a single operation
- When a new account joins, the StackSet automatically provisions:
- VPC with appropriate CIDR blocks
- Subnets across availability zones
- Transit Gateway attachment pointing to the shared TGW ID
- Route table entries directing traffic to the Transit Gateway
- StackSets support automatic deployments for newly created accounts in an organizational unit (OU), achieving the “no manual intervention” requirement
Why this combination wins:
- Cost efficiency: One Transit Gateway ($0.05/hour) instead of 50
- Operational scalability: Zero-touch deployment for new accounts
- Centralized governance: Network team controls routing policies and security
- Compliance: Standardized network architecture enforced via Infrastructure-as-Code
馃拵 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why not Option B (SCPs)?
- Service Control Policies are permission boundaries, not resource sharing mechanisms
- SCPs can only DENY actions; they cannot grant access to specific resources like a Transit Gateway
- This is a common SAP-C02 trap鈥攃onfusing governance tools (SCPs, AWS Config) with operational tools (RAM, StackSets)
- Real-world impact: Choosing this shows a fundamental misunderstanding of AWS Organizations guardrails vs. resource sharing
Why not Option C (VPC Peering with identical CIDRs)?
- Using identical CIDR ranges across VPCs makes routing impossible鈥攜ou’d have overlapping IP addresses
- VPC peering is not transitive; with 200 VPCs you’d need 19,900 peering connections (n*(n-1)/2)
- No automation mechanism described鈥攖his requires manual configuration for each account
- Cost comparison: 19,900 peering connections at $0.01/hour = $1,491/month vs. $36/month for 200 TGW attachments
- This option is intentionally absurd to test whether candidates understand basic networking constraints
Why not Option E (Service Catalog)?
- AWS Service Catalog is a product management tool for distributing pre-approved CloudFormation templates
- It cannot “share” an existing Transit Gateway resource鈥攊t can only provision new resources
- While you could build a Service Catalog product that creates TGW attachments, the question asks how to share the TGW itself
- Service Catalog adds unnecessary complexity (product management, portfolio permissions) for this use case
- Real-world use: Service Catalog is excellent for standardized workload templates (e.g., “approved 3-tier application”), not infrastructure sharing
The Architect Blueprint #
graph TB
subgraph "Management Account"
MS[Management Account
AWS Organizations Root]
TGW[Transit Gateway
tgw-0a1b2c3d4e5f]
RAM[AWS RAM
Resource Share]
StackSet[CloudFormation StackSet
VPC + TGW Attachment Template]
end
subgraph "Member Account 1"
VPC1[VPC 10.1.0.0/16]
ATT1[TGW Attachment]
VPC1 --> ATT1
end
subgraph "Member Account 2"
VPC2[VPC 10.2.0.0/16]
ATT2[TGW Attachment]
VPC2 --> ATT2
end
subgraph "Member Account 50"
VPC50[VPC 10.50.0.0/16]
ATT50[TGW Attachment]
VPC50 --> ATT50
end
MS --> RAM
MS --> StackSet
RAM -->|Share TGW Resource| TGW
TGW -.->|Shared via RAM| ATT1
TGW -.->|Shared via RAM| ATT2
TGW -.->|Shared via RAM| ATT50
StackSet -->|Deploy Stack Instance| VPC1
StackSet -->|Deploy Stack Instance| VPC2
StackSet -->|Deploy Stack Instance| VPC50
style TGW fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style RAM fill:#527FFF,stroke:#232F3E,stroke-width:2px,color:#fff
style StackSet fill:#527FFF,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: The Transit Gateway (created once) is shared via AWS RAM to all member accounts, while CloudFormation StackSets automate the deployment of VPCs and attachments, creating a centrally-managed hub-and-spoke network topology.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons | Automation Capability |
|---|---|---|---|---|---|
| A) AWS RAM Sharing | Low | $0 (RAM itself is free) | Native AWS Organizations integration; supports Transit Gateway sharing; instant propagation; centralized billing | Requires Organizations trusted access enabled; limited to same AWS partition | Fully automated via Organizations integration |
| B) SCP Sharing | N/A | N/A | N/A - SCPs cannot share resources | Fundamentally incorrect approach; SCPs are deny-only policies | N/A |
| C) Identical CIDR + Peering | Very High | ~$1,491/mo for peering + $500/mo operational overhead |
None - this is an anti-pattern | IP address conflicts; non-transitive routing; exponential peering connections; no centralized control; manual configuration | None - requires manual intervention per account |
| D) CloudFormation StackSets | Medium (initial setup) Low (ongoing) |
$0 (CloudFormation is free) TGW attachments: ~$7,200/mo (200 脳 $36) |
Fully automated deployment; version-controlled infrastructure; drift detection; works across regions; auto-deploys to new accounts | Requires YAML/JSON expertise; initial learning curve; requires proper IAM trust configuration | Full automation with auto-deployment to new OUs |
| E) Service Catalog | High | $0 (Service Catalog is free) | Governance framework; end-user self-service | Cannot share existing resources; adds unnecessary complexity; requires product management; doesn’t solve the core sharing problem | Partial - requires manual product launching |
Cost Analysis Deep Dive (200 VPCs across 50 accounts):
-
Transit Gateway Approach (A+D):
- 1 TGW: $36/month
- 200 attachments: $7,200/month
- Data processing: ~$2,000/month (100TB inter-VPC at $0.02/GB)
- Total: ~$9,236/month
-
VPC Peering Approach (C):
- 19,900 peering connections: $1,491/month
- Data transfer: ~$1,000/month (same-region peering data transfer is free, but inter-region would be $0.01/GB)
- Operational overhead (estimated 40 hours/month at $150/hour): $6,000/month
- Total: ~$8,491/month + massive operational burden
The FinOps Verdict: While superficially cheaper, VPC peering at this scale is operationally unsustainable and prevents centralized security policies (no network firewalling, no centralized traffic inspection). The Transit Gateway approach provides better ROI when factoring operational costs and enables advanced capabilities (AWS Network Firewall integration, centralized egress, etc.).
Real-World Practitioner Insight #
Exam Rule #
“For SAP-C02, when you see multi-account resource sharing + Transit Gateway, always pick AWS RAM. When you see automate infrastructure across accounts, always pick CloudFormation StackSets. SCPs are for permissions boundaries, not resource sharing. Service Catalog is for end-user provisioning, not infrastructure sharing.”
Real World #
In production environments, I would enhance this architecture with:
-
Separate Network Account: Instead of using the management account, create a dedicated
network-prodaccount to own the Transit Gateway (management accounts should be reserved for billing and organization management only) -
Multi-Region Transit Gateway Peering: For disaster recovery, deploy Transit Gateways in secondary regions and peer them using TGW peering (adds $0.05/hour per peering attachment)
-
Hybrid StackSets + Terraform: Many enterprises use Terraform for its superior state management and multi-cloud support. You’d use:
- AWS Organizations + RAM for the Transit Gateway sharing (still AWS-native)
- Terraform with organization-wide modules for VPC/attachment deployment
- Terragrunt for DRY configuration across accounts
-
Network Segmentation: Instead of one flat Transit Gateway, use multiple route tables within the TGW to segment traffic (production VPCs can’t route to development VPCs), or deploy separate Transit Gateways per environment with Resource Access Manager sharing scoped to specific OUs
-
Cost Allocation Tags: Tag all Transit Gateway attachments with
CostCenter,Environment, andProductTeamto enable chargeback via AWS Cost Explorer -
Monitoring: Deploy VPC Flow Logs to S3, analyze with Amazon Athena to identify top talkers, and right-size Transit Gateway attachments (you can delete unused attachments automatically using AWS Config rules + Lambda)
-
The IPAM Integration: Use AWS IPAM (IP Address Manager) to automatically assign non-overlapping CIDR blocks to new VPCs, preventing the networking nightmare of overlapping IPs as you scale to 100+ accounts
The gap the exam doesn’t test: How do you handle the transition period? You can’t migrate 200 VPCs overnight. The real project involves:
- Running VPC peering and Transit Gateway in parallel during migration
- Using weighted routing in Route 53 to gradually shift traffic
- Decomissioning peering connections only after validating connectivity via TGW
- Estimated migration timeline for 200 VPCs: 3-4 months with a 2-person team