Study guide
Technical reference and lesson notes
This lesson covers Amazon VPC peering, which allows two Amazon Virtual Private Clouds to communicate privately using AWS networking. For the AWS Certified Solutions Architect – Professional SAP-C02 exam, VPC peering is important because it often appears in scenario questions involving multi-VPC connectivity, cross-account networking, CIDR planning, route table design, DNS behavior, and when to choose AWS Transit Gateway instead.
At the Professional level, the exam is less likely to ask, “What is VPC peering?” and more likely to ask whether VPC peering is the correct architecture for a specific scale, routing, governance, or operational requirement.
Key Concepts
What Is VPC Peering?
VPC peering is a private network connection between two Amazon VPCs. Once configured correctly, resources in one VPC can communicate with resources in the other VPC using private IP addresses.
VPC peering can be used between:
- VPCs in the same AWS account
- VPCs in different AWS accounts
- VPCs in the same Region
- VPCs in different Regions
The connection uses AWS’s internal network instead of traversing the public internet. This provides private connectivity between VPCs while avoiding internet gateways, public IP routing, and VPN tunnels for VPC-to-VPC communication.
Core Requirements for VPC Peering
A VPC peering connection alone does not automatically enable traffic. Several conditions must be met.
Non-Overlapping CIDR Blocks
The VPC CIDR ranges must not overlap.
For example:
| VPC | CIDR Block |
|---|---|
| VPC A | 10.0.1.0/24 |
| VPC B | 10.0.2.0/24 |
This is valid because the CIDR ranges are unique.
This would not be valid:
| VPC | CIDR Block |
|---|---|
| VPC A | 10.0.0.0/16 |
| VPC B | 10.0.0.0/16 |
Overlapping IP space creates routing ambiguity. AWS will not allow a valid peering connection when the IPv4 CIDR blocks overlap.
Peering Request and Acceptance
A VPC peering connection has a requester side and an accepter side.
For same-account peering, this is simple. For cross-account peering, the owner of the accepter VPC must accept the peering request.
The basic workflow is:
- Create the VPC peering connection.
- Accept the peering request from the peer VPC side.
- Update route tables in both VPCs.
- Update security groups and network ACLs as needed.
- Enable DNS resolution if required.
Routing with VPC Peering
VPC peering requires explicit route table entries. AWS does not dynamically update route tables for you.
A typical route looks like this:
| Destination | Target |
|---|---|
| Peer VPC CIDR block | VPC peering connection ID |
Example:
| VPC | Local CIDR | Peer CIDR | Route Target |
|---|---|---|---|
| Management VPC | 10.10.0.0/16 | 10.20.0.0/16 | pcx-xxxxxxxx |
| Production VPC | 10.20.0.0/16 | 10.10.0.0/16 | pcx-yyyyyyyy |
For bidirectional communication, both VPCs need routes pointing to each other through the peering connection.
If only one side has a route, traffic may leave one VPC but not return properly.
Security Groups and Network ACLs
VPC peering provides network reachability, but it does not override security controls.
You still need to allow traffic through:
- Security groups
- Network ACLs
- Operating system firewalls
- Application-level access controls
A common approach is to allow inbound traffic from the peer VPC CIDR block.
Example:
| Resource | Rule |
|---|---|
| EC2 instance in Production VPC | Allow TCP 443 from Management VPC CIDR |
| Database in Shared Services VPC | Allow TCP 5432 from Application VPC CIDR |
For the exam, remember that routing and security are separate. A peering connection plus route table entries does not guarantee that the application will work.
No Transitive Routing
VPC peering is not transitive.
This is one of the most important exam points.
If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot reach VPC C through VPC B.
Example:
| Peering Connection | Exists? |
|---|---|
| VPC A to VPC B | Yes |
| VPC B to VPC C | Yes |
| VPC A to VPC C | No |
In this design, VPC A cannot communicate with VPC C through VPC B. To allow communication, you must create a direct peering connection between VPC A and VPC C.
This limitation makes VPC peering simple and effective for small designs, but difficult to manage at scale.
Full Mesh VPC Peering
If every VPC must communicate directly with every other VPC, you need a full mesh topology.
For four VPCs, the required peering connections are:
- VPC A to VPC B
- VPC A to VPC C
- VPC A to VPC D
- VPC B to VPC C
- VPC B to VPC D
- VPC C to VPC D
That is six peering connections.
Each VPC also needs route table entries for the other VPC CIDR blocks.
For four VPCs:
| Item | Quantity |
|---|---|
| VPCs | 4 |
| Peering connections | 6 |
| Minimum route entries per VPC | 3 |
| Minimum total route entries | 12 |
For eight VPCs:
| Item | Quantity |
|---|---|
| VPCs | 8 |
| Peering connections | 28 |
| Minimum route entries per VPC | 7 |
| Minimum total route entries | 56 |
The number of connections grows quickly as more VPCs are added. This is why VPC peering is not usually the best choice for large multi-VPC environments.
VPC Peering Scalability Considerations
VPC peering works well for simple, direct connectivity requirements.
Good use cases include:
- One application VPC connecting to one shared services VPC
- Cross-account access between two specific VPCs
- Simple private communication between development and tooling VPCs
- Low-latency private connectivity between two VPCs
- Limited inter-Region VPC-to-VPC communication
Poor use cases include:
- Many VPCs requiring any-to-any connectivity
- Centralized inspection through firewalls
- Complex hub-and-spoke routing
- Environments requiring route propagation
- Large enterprise landing zones with many accounts and VPCs
- Designs requiring transitive routing
When scale increases, AWS Transit Gateway is usually the better answer.
VPC Peering vs AWS Transit Gateway
AWS Transit Gateway acts as a regional network hub. VPCs attach to the transit gateway, and routing is controlled through Transit Gateway route tables.
VPC peering is one-to-one. Transit Gateway supports centralized routing between many VPCs and hybrid networks.
VPC Peering
Use VPC peering when:
- The design is simple.
- Only two or a small number of VPCs need connectivity.
- You do not need transitive routing.
- You want direct VPC-to-VPC private connectivity.
- You want to avoid additional Transit Gateway complexity or cost.
AWS Transit Gateway
Use Transit Gateway when:
- Many VPCs need connectivity.
- You need hub-and-spoke architecture.
- You need centralized route control.
- You need transitive routing between VPCs.
- You need to connect many VPCs to VPN or Direct Connect.
- You need scalable multi-account networking.
For the SAP-C02 exam, if the scenario says “many VPCs,” “hundreds of accounts,” “centralized routing,” “shared services,” “hub-and-spoke,” or “transitive routing,” AWS Transit Gateway is usually the expected answer.
VPC Peering and DNS Resolution
VPC peering does not automatically guarantee that DNS names will resolve the way you expect.
Important DNS points:
- Private IP communication can work through peering when routing and security are configured.
- DNS behavior may require enabling DNS resolution support on the peering connection.
- If using public DNS hostnames for EC2 instances, DNS resolution settings determine whether those names resolve to private IPs across the peering connection.
- For more complex private name resolution, Amazon Route 53 private hosted zones or Route 53 Resolver may be required.
In real environments, DNS is often the difference between “the network works” and “the application works.”
Inter-Region VPC Peering
VPC peering can be used between VPCs in different AWS Regions.
This is useful when:
- Applications need private cross-Region communication.
- A workload in one Region must access shared services in another Region.
- Disaster recovery architectures require private connectivity between Regions.
However, inter-Region peering still has the same core limitations:
- No transitive routing
- Route tables must be updated
- CIDR ranges must not overlap
- Security groups and NACLs must allow the traffic
- DNS resolution may need to be explicitly configured
For large global networks, Transit Gateway peering or other centralized network designs may be more appropriate.
VPC Peering Compared to VPN and Direct Connect
VPC peering is for private VPC-to-VPC communication inside AWS.
AWS Site-to-Site VPN and AWS Direct Connect are primarily used for hybrid connectivity between AWS and external networks, such as on-premises data centers.
AWS Site-to-Site VPN
Use Site-to-Site VPN when you need encrypted connectivity between AWS and an external network over the internet.
Common use cases:
- Branch office to AWS
- Data center to AWS
- Temporary hybrid connectivity
- Backup connection for Direct Connect
AWS Direct Connect
Use Direct Connect when you need private, dedicated connectivity from on-premises environments to AWS.
Common use cases:
- High-throughput hybrid connectivity
- Lower and more consistent latency than internet VPN
- Large data transfers
- Enterprise data center integration
VPC Peering
Use VPC peering when the requirement is direct private connectivity between two VPCs.
Architecture Decision Guide
| Scenario | Best AWS Choice | Why |
|---|---|---|
| Two VPCs need simple private communication | VPC Peering | Direct one-to-one private connectivity with straightforward routing |
| Four VPCs need full mesh communication | VPC Peering may work, but evaluate carefully | It is manageable at small scale, but route and peering complexity grows |
| Eight or more VPCs need any-to-any connectivity | AWS Transit Gateway | Peering becomes operationally complex; Transit Gateway provides centralized routing |
| VPC A must reach VPC C through VPC B | AWS Transit Gateway | VPC peering does not support transitive routing |
| Multiple AWS accounts need centralized shared services access | AWS Transit Gateway | Better for hub-and-spoke, shared services, and enterprise account structures |
| On-premises data center needs private connectivity to AWS | AWS Direct Connect | Designed for dedicated hybrid connectivity |
| On-premises data center needs encrypted connectivity over the internet | AWS Site-to-Site VPN | Provides IPsec VPN connectivity to AWS |
| Two VPCs have overlapping IPv4 CIDRs | Redesign IP space or use another architecture | VPC peering requires non-overlapping IPv4 CIDRs |
| Application works by IP but fails by hostname | Check DNS resolution settings | Peering does not automatically guarantee desired DNS behavior |
| Need centralized inspection between many VPCs | Transit Gateway with inspection architecture | VPC peering is not ideal for centralized traffic inspection |
Exam-Relevant Takeaways
VPC peering is a one-to-one private connection between two VPCs.
The peer VPCs must have non-overlapping IPv4 CIDR blocks.
Creating the peering connection is not enough. You must also update route tables and security controls.
VPC peering does not support transitive routing.
If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot communicate with VPC C unless VPC A and VPC C are directly peered.
Full mesh peering becomes complex as the number of VPCs grows.
AWS Transit Gateway is usually the better choice for large-scale multi-VPC networking, hub-and-spoke designs, shared services, and transitive routing.
VPC peering can work across accounts and across Regions.
DNS resolution behavior may need to be explicitly configured.
Security groups, NACLs, and OS firewalls still apply.
VPC peering is not a replacement for Direct Connect or Site-to-Site VPN when the requirement is hybrid connectivity to on-premises networks.
Common Exam Traps
Trap 1: Assuming VPC Peering Is Transitive
Incorrect assumption:
“VPC A can reach VPC C because both are connected to VPC B.”
Correct understanding:
VPC peering is not transitive. VPC A must be directly peered with VPC C, or you need a service such as AWS Transit Gateway.
Trap 2: Forgetting Route Table Updates
A peering connection can exist but still not pass traffic if routes are missing.
Each VPC route table must include a route to the peer VPC CIDR block through the peering connection.
Trap 3: Ignoring Return Traffic
Routing must work both ways. If only one VPC has a route to the other, traffic may fail because the response path is missing.
Trap 4: Overlapping CIDR Blocks
VPC peering requires non-overlapping CIDR ranges. If the scenario includes overlapping CIDRs, VPC peering is not the right answer.
Trap 5: Choosing VPC Peering for Large Multi-VPC Environments
VPC peering may look simple at first, but it becomes hard to manage when many VPCs require full connectivity.
For large networks, AWS Transit Gateway is usually the better design.
Trap 6: Confusing VPC Peering with Hybrid Connectivity
VPC peering connects VPCs to other VPCs. It is not the primary service for connecting a data center to AWS.
For hybrid connectivity, think Site-to-Site VPN or Direct Connect.
Trap 7: Assuming DNS Automatically Works
Private IP routing and DNS name resolution are separate concerns. DNS resolution across peering may require explicit configuration.
Real-World Engineer Notes
In real environments, VPC peering is often attractive because it is simple and direct. For a small number of VPCs, it can be easy to deploy and operate.
However, the operational burden grows quickly.
When managing VPC peering, engineers need to track:
- CIDR allocations
- Peering request ownership
- Cross-account acceptance
- Route table updates
- Security group rules
- Network ACLs
- DNS resolution settings
- Change control and documentation
- Troubleshooting paths for asymmetric routing
A common real-world issue is incomplete routing. One team creates the peering connection, but only one side updates its route table. The result is failed connectivity even though the peering connection shows as active.
Another common issue is security group scope. The route may be correct, but the destination instance or database still blocks traffic because the peer VPC CIDR was never allowed.
CIDR planning is also critical. If multiple business units create VPCs independently without central IP address management, overlapping CIDRs can block future peering or force painful readdressing work.
For enterprise environments, a centralized networking model is usually preferred. AWS Transit Gateway, AWS Organizations, AWS Resource Access Manager, and standardized account/VPC patterns are more scalable than manually managing large numbers of peering connections.
For troubleshooting, validate in this order:
- Confirm the VPC peering connection is active.
- Confirm CIDR ranges do not overlap.
- Confirm route tables on both sides.
- Confirm security groups.
- Confirm network ACLs.
- Confirm OS-level firewall rules.
- Test by private IP.
- Then test DNS.
- Review VPC Flow Logs if traffic still fails.
Quick Reference Summary
VPC peering provides private connectivity between two VPCs.
It is a one-to-one relationship.
It works within the same account, across accounts, within the same Region, and across Regions.
VPC CIDR blocks must not overlap.
Route tables must be manually updated.
Security groups and NACLs must allow traffic.
VPC peering does not support transitive routing.
Full mesh peering becomes complex as the number of VPCs grows.
Use AWS Transit Gateway for scalable multi-VPC routing.
Use Site-to-Site VPN or Direct Connect for hybrid connectivity.
DNS resolution across peering may require additional configuration.
Flashcards
Q: What is VPC peering?
A: VPC peering is a private network connection between two Amazon VPCs that allows resources to communicate using private IP addresses.
Q: Does VPC peering support transitive routing?
A: No. VPC peering is not transitive. Each VPC must be directly peered with any VPC it needs to communicate with.
Q: What happens if two VPCs have overlapping IPv4 CIDR blocks?
A: VPC peering cannot be used because overlapping CIDRs create routing ambiguity.
Q: Is creating a VPC peering connection enough to allow communication?
A: No. You must also update route tables, security groups, NACLs, and possibly DNS settings.
Q: What route table target is used for traffic to a peer VPC?
A: The VPC peering connection ID.
Q: When should AWS Transit Gateway be preferred over VPC peering?
A: When many VPCs need scalable connectivity, hub-and-spoke routing, centralized shared services access, or transitive routing.
Q: Can VPC peering be used across AWS accounts?
A: Yes. VPC peering can be configured across AWS accounts, but the accepter side must accept the peering request.
Q: Can VPC peering be used across Regions?
A: Yes. Inter-Region VPC peering is supported.
Q: Why does full mesh VPC peering become difficult to manage?
A: The number of peering connections and route table entries grows rapidly as more VPCs are added.
Q: How many peering connections are required for four VPCs in a full mesh?
A: Six peering connections.
Q: How many peering connections are required for eight VPCs in a full mesh?
A: Twenty-eight peering connections.
Q: What is a common DNS issue with VPC peering?
A: DNS names may not resolve to private IP addresses across the peering connection unless DNS resolution is configured correctly.
Q: Is VPC peering the right solution for on-premises connectivity?
A: No. For on-premises connectivity, use AWS Site-to-Site VPN or AWS Direct Connect.
Q: Does VPC peering bypass security groups?
A: No. Security groups, NACLs, and host firewalls still apply.
Q: What is the best first test when troubleshooting peered VPC connectivity?
A: Test private IP connectivity after confirming the peering connection, route tables, and security rules.
Practice Questions
Question 1:
A company has three VPCs: VPC A, VPC B, and VPC C. VPC A is peered with VPC B. VPC B is peered with VPC C. The company wants instances in VPC A to communicate with instances in VPC C. What should the solutions architect recommend?
A. Add a route in VPC A pointing to VPC C through the VPC A-to-B peering connection
B. Add a route in VPC C pointing to VPC A through the VPC C-to-B peering connection
C. Create a direct VPC peering connection between VPC A and VPC C or use AWS Transit Gateway
D. Enable DNS resolution on both existing VPC peering connections
Correct Answer:
C
Explanation:
VPC peering does not support transitive routing. VPC A cannot reach VPC C through VPC B. The VPCs must be directly peered, or a transitive routing service such as AWS Transit Gateway should be used.
Question 2:
A company wants to connect two VPCs using private IP addresses. VPC A uses 10.0.0.0/16 and VPC B also uses 10.0.0.0/16. What is the main issue with using VPC peering?
A. VPC peering does not support private IP communication
B. VPC peering requires overlapping CIDR blocks
C. VPC peering cannot be created because the IPv4 CIDR blocks overlap
D. VPC peering only works within a single Availability Zone
Correct Answer:
C
Explanation:
VPC peering requires non-overlapping IPv4 CIDR ranges. Overlapping CIDRs create routing ambiguity and prevent a valid peering design.
Question 3:
A company has eight VPCs that all need to communicate with each other. The network team wants to reduce operational complexity and avoid managing many individual peering connections. Which AWS service is the best fit?
A. VPC Peering
B. AWS Transit Gateway
C. Internet Gateway
D. NAT Gateway
Correct Answer:
B
Explanation:
For many VPCs requiring scalable any-to-any or hub-and-spoke connectivity, AWS Transit Gateway is the better choice. VPC peering would require many individual connections and route table entries.
Question 4:
A solutions architect creates a VPC peering connection between a Management VPC and a Production VPC. The peering connection is active, but instances cannot communicate. What should the architect check first?
A. Whether an internet gateway is attached to both VPCs
B. Whether both VPC route tables have routes to the peer CIDR through the peering connection
C. Whether NAT gateways exist in both VPCs
D. Whether both VPCs are in the same Availability Zone
Correct Answer:
B
Explanation:
An active peering connection does not automatically create routes. Route tables must be updated on both sides to direct traffic to the peer VPC CIDR through the peering connection.
Question 5:
An application in one VPC can connect to an EC2 instance in a peered VPC using its private IP address, but DNS hostname-based access does not work as expected. What is the most likely area to investigate?
A. NAT gateway route configuration
B. DNS resolution settings for the VPC peering connection
C. Whether the instance has a public IP address
D. Whether the VPC has an internet gateway
Correct Answer:
B
Explanation:
Private IP routing and DNS resolution are separate. DNS behavior across VPC peering may require DNS resolution settings to be enabled or additional DNS architecture such as Route 53 private hosted zones or Route 53 Resolver.