Configure Cross-Region VPC Peering in AWS – SAP-C02 Study Guide

Purpose of This Lesson

VPC peering provides private network connectivity between two VPCs using private IP addresses. This lesson demonstrates peering two VPCs in different AWS Regions within the same account, configuring routes and security groups, and validating connectivity between EC2 instances.

The key implementation point is that creating the peering connection alone is not enough. Both VPCs need appropriate route table entries, and their security groups must permit the intended traffic.

Key Concepts

Cross-Region VPC peering

A VPC peering connection can connect VPCs in different AWS Regions. Traffic remains on the AWS network and does not require an internet gateway, NAT gateway, VPN, or public IP address.

The example uses:

• A VPC in us-east-1 with CIDR 10.0.0.0/16
• A VPC in us-west-1 with CIDR 10.1.0.0/16
• One EC2 instance in each VPC
• A peering connection between the two VPCs
• Private-IP connectivity for ICMP and HTTP testing

VPC CIDR ranges must not overlap. Overlapping address spaces prevent the VPCs from being peered and create ambiguous routing.

Requester and accepter roles

Creating a peering connection establishes a request from the requester VPC to the accepter VPC. The accepter must approve the request before the connection becomes active.

For VPCs in different Regions, use the correct Region-specific VPC console when creating and accepting the request. A peering connection can also span accounts, but cross-account requests require the appropriate account owner to accept them.

Route table configuration

VPC peering does not automatically update route tables. Add a route in each VPC for the other VPC’s CIDR block, using the peering connection as the target.

Example routes:

VPC in us-east-1 route table:
10.1.0.0/16 -> pcx-xxxxxxxx

VPC in us-west-1 route table:
10.0.0.0/16 -> pcx-xxxxxxxx

The route must be added to the route table associated with the subnets containing the communicating resources. Updating an unrelated route table will not provide connectivity.

Security group requirements

Security groups must allow the required traffic from the remote VPC’s CIDR block. In this lab, the rules permit:

• TCP port 22 for SSH or Instance Connect administration
• TCP port 80 for HTTP testing
• ICMP from the opposite VPC for ping

A route can be correct while traffic still fails because of security group rules. Security groups are stateful, so return traffic for an allowed connection is automatically permitted, subject to other network controls.

Connectivity validation

Testing should be performed in both directions:

1. Connect to the instance in the first VPC.
2. Ping the private IP address of the instance in the second VPC.
3. Use curl against the remote instance’s private IP address.
4. Repeat the tests from the second VPC back to the first.

A successful test confirms that routing, security group permissions, and the application listener are aligned.

CloudFormation and Region-specific AMIs

The infrastructure can be deployed with separate CloudFormation stacks, one in each Region. EC2 AMI IDs are Region-specific, so an AMI ID that works in us-east-1 cannot automatically be reused in us-west-1.

When using templates for multi-Region deployments, parameterize or update Region-specific values such as:

• AMI IDs
• Availability Zones
• Subnet identifiers
• VPC and route table identifiers

Exam-Relevant Takeaways

• VPC peering supports private connectivity between VPCs, including VPCs in different Regions.
• The VPC CIDR ranges must not overlap.
• The peering connection must be accepted by the accepter VPC before use.
• Routes must be added manually on both sides of the connection.
• Each route should target the VPC peering connection and use the destination VPC’s CIDR range.
• Security groups must allow traffic from the remote VPC’s CIDR block and the required protocol or port.
• VPC peering is not transitive. If VPC A peers with VPC B and VPC B peers with VPC C, A cannot reach C through B.
• VPC peering does not provide automatic DNS, routing, or security group configuration.
• A deleted peering connection can leave stale route entries in a blackhole state. Remove those routes during cleanup.
• For many-to-many or centrally governed connectivity, evaluate AWS Transit Gateway instead of creating a large mesh of peering connections.

Architecture Decision Guide

Requirement	Appropriate choice	Important consideration
Private connectivity between two VPCs	VPC peering	Configure routes and security controls in both VPCs
Connectivity between VPCs in different Regions	Inter-Region VPC peering	Traffic uses private AWS networking; account and Region context must be correct
Many VPCs with centralized routing	AWS Transit Gateway	Avoids a complex full-mesh peering design
Connectivity from on-premises to AWS	AWS Site-to-Site VPN or AWS Direct Connect	VPC peering alone does not connect on-premises networks
Overlapping VPC CIDR ranges	Redesign addressing or use an appropriate translation architecture	Overlapping CIDRs prevent standard VPC peering
One-way application access	Peering plus routes and narrowly scoped security rules	Ensure the return path and stateful controls are valid

Common Exam Traps

Assuming peering automatically propagates routes

Creating a peering connection does not change route tables. Add a route for the remote CIDR in every relevant subnet route table.

Configuring only one side

Routing must work in both directions. Add the remote VPC route on both sides, and verify that security groups permit the intended traffic.

Using public IP addresses unnecessarily

VPC peering is intended for private connectivity. Applications should communicate using private IP addresses or private DNS names where appropriate.

Expecting transitive routing

Peering connections cannot be used as transit paths. A VPC cannot route through a peered VPC to reach a third VPC, VPN, or other network unless the architecture uses a service designed for transit routing.

Ignoring the acceptance step

A peering request remains pending until the accepter accepts it. An inactive or pending connection cannot provide the expected traffic path.

Choosing an overlapping address space

Two VPCs with overlapping CIDR ranges cannot be peered. Address planning must occur before deployment.

Forgetting Region-specific resources

AMI IDs and many other resource identifiers are Region-specific. A CloudFormation template that works in one Region may fail or launch the wrong resource when reused elsewhere without updated parameters.

Leaving blackhole routes behind

After deleting a peering connection, routes that targeted it may become invalid. A route in blackhole status has no usable target and should be removed or replaced.

Real-World Engineer Notes

• Use explicit, least-privilege security group rules rather than allowing the entire remote VPC CIDR when only one application port is required.
• Confirm the subnet route table association, not merely the existence of a route in some route table in the VPC.
• Use VPC Flow Logs, Reachability Analyzer, and instance-level tests to distinguish routing failures from security group or application failures.
• For cross-Region designs, consider latency, data transfer charges, encryption requirements, and the operational impact of regional failure.
• A peering connection is point-to-point. A growing number of VPCs can create a difficult-to-manage peering mesh; Transit Gateway is generally more suitable for centralized connectivity.
• Delete test stacks and associated network connections after a lab. Orphaned resources can generate cost and leave confusing route entries.

Quick Reference Summary

1. Deploy both VPCs with non-overlapping CIDR ranges.
2. Deploy resources in each VPC.
3. Create a VPC peering request from the requester VPC.
4. Accept the request in the accepter Region/account.
5. Add the remote CIDR route to both sides' relevant route tables.
6. Permit required ports and protocols in security groups.
7. Test with private IP addresses in both directions.
8. Remove peering connections and stale routes during cleanup.

Flashcards

1. Q: What type of connectivity does VPC peering provide?

A: Private IP connectivity between two VPCs over AWS networking.

1. Q: Can VPC peering connect VPCs in different AWS Regions?

A: Yes. Inter-Region VPC peering supports private connectivity between VPCs in different Regions.

1. Q: What must be true about the VPC CIDR ranges before peering?

A: They must not overlap.

1. Q: Is a peering request active immediately after creation?

A: No. The accepter must accept the request first.

1. Q: Does creating a peering connection automatically add routes?

A: No. Routes to the remote VPC CIDR must be added manually.

1. Q: What should the target of a peering route be?

A: The VPC peering connection, identified by a pcx- ID.

1. Q: Where must peering routes be configured?

A: In the route tables associated with the subnets that contain the communicating resources, on both sides.

1. Q: What security group source is commonly used for private VPC-to-VPC traffic?

A: The CIDR block of the remote VPC, narrowed further when practical.

1. Q: Is VPC peering transitive?

A: No. A VPC cannot use another peered VPC as a transit router.

1. Q: What does a blackhole route indicate after deleting a peering connection?

A: The route’s target no longer exists or is unavailable.

1. Q: Why can an EC2 AMI ID need to be changed in a multi-Region CloudFormation deployment?

A: AMI IDs are Region-specific.

1. Q: Which service is often better than a large peering mesh for centralized connectivity across many VPCs?

A: AWS Transit Gateway.

Practice Questions

Question 1

A company has two VPCs in us-east-1 and us-west-1 with non-overlapping CIDR ranges. A peering connection is active, but an EC2 instance in the first VPC cannot connect to an HTTP server in the second VPC using its private IP address. The security groups already allow TCP port 80 from the remote VPC CIDR. What is the most likely missing configuration?

Correct answer: A route to the remote VPC CIDR is missing from one or both relevant subnet route tables.

Explanation: VPC peering does not automatically propagate routes. Each side needs a route for the other VPC’s CIDR, with the peering connection as the target.

Question 2

VPC A peers with VPC B, and VPC B peers with VPC C. An instance in VPC A must access an instance in VPC C through VPC B. Which change enables this traffic using only standard VPC peering?

Correct answer: None. Standard VPC peering is non-transitive.

Explanation: VPC A cannot use VPC B as a router to reach VPC C. Use a transit architecture such as AWS Transit Gateway, or establish a direct connection where appropriate.

Question 3

An administrator creates a cross-account VPC peering request. The requester sees the connection in a pending state, and no traffic flows. What should the administrator do?

Correct answer: Have the owner of the accepter VPC accept the peering request, then configure routes and security groups.

Explanation: A peering request must be accepted by the accepter account. Acceptance alone still does not configure routes or security rules.

Question 4

A CloudFormation template successfully launches an EC2 instance in us-east-1 but fails in us-west-1 because the specified AMI cannot be found. What is the likely cause?

Correct answer: The template uses an AMI ID that is valid only in us-east-1.

Explanation: AMI IDs are Region-specific. Use a Region-appropriate AMI or parameterize the AMI mapping for each deployment Region.

Question 5

A VPC peering connection was deleted, but a route table now shows a route with a blackhole status. What should be done?

Correct answer: Remove the stale route or replace it with a valid target.

Explanation: The route still references the deleted peering connection. It cannot forward traffic and should be cleaned up to prevent operational confusion.